github-tools
Possible bug in version ranges for generating a release with --tags
Background
I originally started this issue for a feature request, but I see now that this might be a bug. I've updated the title to reflect this.
In our current setup, we utilize master only development, in which we deploy to different environments based on tags:
// Deploys to dev test
npm version 1.0.1-beta.x
// Deploys to acceptance test
npm version 1.0.1-rc.x
// Deploys to production
npm version 1.0.1
This results with the usage of gren that only the 1.0.1-beta.x contains the full release notes since last release, and not 1.0.1.
Is it possible to have a feature that enables gren to concatenate, or use the preferred release notes for a tag? For example:
gren release --prerelease --override --tags=v1.2.0..v1.2.0-beta.0
Conclusion
I see that this might be a potential bug, as gren is probably not accepting version ranges in tags correctly, specifically, between prereleases?
Another relevant scenario
Old production release is 0.58.1, I have a 1.2.0-rc.0 version not in production yet.
gren release --override --tags=v1.2.0..v0.58.1
This will populate release notes with ALL the commits and tags created historically between those tags, including tags like 1.3.0-beta.0 🤦♂️
Maybe there is a opaque documentation. Just to be clear:
Tags
--tags=v1.2.0..v0.58.1 will produce a single release notes output, not individual release notes output for every tag in between those tags.
To do that you can run gren with the --tags=all flag.
Ignore tags
You can ignore tags based on strings, which means that:
gren release --override --tags=all --ignore-tags-with=beta,rc,alpha
Will not create releases for those tags that contain one between beta, rc and alpha.
Not sure if is just a documentation problem, or I'm missing something.
Well, --tags=v1.2..0..v0.58.1 should give me a release note with everything between those, incrementally from v0.58.1, v1.0.0 ... to v1.2.0. v1.3.0* should not be there at all, regardless of ignoring tags.
Yes, so --tags=v1.2.0..v0.58.1 will create a release for v1.2.0 with every issue (or commit) done in between these two tags. Is it not happening?
If running --tags=v1.2.0..v0.58.1 gives you every tag CREATED between those tags, and that makes no sense, since there is no guarantee that the tags CREATED between those tags are the tags RELEASED. I think that with the current setup, running --tags=v1.2.0..v0.58.1 it is assumed that you can't create a 1.4.0-rc before a 1.2.0.
--tags=v1.2.0..v0.58.1 should only collect the tags ascending/descending by semver, not time.
To clarify:
Current method
Running --tags=v1.2.0..v0.58.1:
- Start with tag v1.2.0 and traverse backwards (this tag is created on Friday)
- tag 1.2.0-rc.0 found, continuing (This tag is created on Thursday)
- tag 1.4.0-beta.0 found, continuing (This tag is created on Wednesday)
- tag 0.58.1 found, continuing (This tag is created on Tuesday)
Desired method
Running --tags=v1.2.0..v0.58.1:
- tag 1.4.0-beta.0 found, continuing (This tag is created on Wednesday)
- Start with tag v1.2.0 and traverse backwards (this tag is created on Friday)
- tag 1.2.0-rc.0 found, continuing (This tag is created on Thursday)
- tag 0.58.1 found, continuing (This tag is created on Tuesday)
As far as I understand, based on how the Github API works and how GREN resolves the tags, they end up being sorted by date of the commit they reference. Seems this is confirmed by scenario outlined above.
I believe there the issue here is really to implement correct semver sorting, as that's not actually what's happening right now.
But also from your comment @phun-ky, seems GREN is not considering whether tag is already released? Add an additional option? Is there actually a case where we want to include the unreleased tags?
On a further note:
I'd like to understand a bit more the context of where a 1.3* tag is referencing a commit prior to a 1.2* commit. I believe that there needs to be a consistent, sane behavior and API for this, and I think semver sorting is the reasonable, expected default (basically how it's expected to work ATM). However, learning more about how this tag/commit ordering might come about in the wild would be beneficial for the context of this issue :)
With out deployment scenario, we release versions post-fixed with -beta.[0-9*] to a test environment for technical tests, and then we release versions with -rc.[0-9*] to an acceptance test environment for our testers, and then we release without prefixes to production.
So if I want to release 1.2.0 to production and we already have 1.4.0-beta.0 in the test environment, that release/tag/version is in the release notes/changelog