feat: add PrereleaseVersioningStrategy #1981
Conversation
|
@jskeet This should be the last blocker for the google-cloud-dotnet migration. What's unclear to me is what you want the |
|
"1.2.3-beta01 + feat" should be 1.3.0-beta01, but "1.2.0-beta01 + feat" should be "1.2.0-beta02". My rationale is that 1.2.3-beta01 should still be logically a patch on the 1.2.x series, and adding a feature means that it should be promoted to 1.3.x... whereas 1.2.0-beta01 suggests "we haven't released 1.2.0 yet, so we can keep adding features to it". Hope that makes sense! Will now review the code... |
| const strategy = new PrereleaseVersioningStrategy(); | ||
| const oldVersion = Version.parse('0.1.2'); | ||
| const newVersion = await strategy.bump(oldVersion, commits); | ||
| expect(newVersion.toString()).to.equal('1.0.0'); |
There was a problem hiding this comment.
We don't actually use "less than 0" majors, but I'd expect this to be 0.2.0 personally. (Basically "before 1.0, there are no guarantees.") I've now read that this is the "bumpMinorPreMajor" behavior, but I'd personally expect it to be the default. It feels very weird for "I've taken a breaking change" to be the trigger to go from 0.x to 1.0.
| breaking: false, | ||
| }, | ||
| ]; | ||
| it('can bump a major', async () => { |
There was a problem hiding this comment.
Can you add a test for a breaking change on a various pre-release aspects? For example:
- 1.0.0-beta01 => 1.0.0-beta02
- 2.0.0-beta01 => 2.0.0-beta02
- 1.0.1-beta01 => 2.0.0-beta02
- 1.1.0-beta01 => 2.0.0-beta01
- 1.1.1-beta01 => 2.0.0-beta01
There was a problem hiding this comment.
- 1.0.1-beta01 => 2.0.0-beta02
This one should probably be 1.0.1-beta01 => 2.0.0-beta01?
There was a problem hiding this comment.
Yup, sorry about that. Copy and paste error, I suspect.
Of course, there's actually more subtlety here - if the breaking change is only breaking with respect to a new feature introduce in a beta, then it can just be beta02. But we don't really have that much information, as far as I'm aware. This is why I'm expecting to keep looking at changes fairly carefully, manually, in order to check that release-please is doing the right thing :)
| breaking: false, | ||
| }, | ||
| ]; | ||
| it('can bump a minor', async () => { |
There was a problem hiding this comment.
Again, I'd like to see the impact of features on pre-releases:
- 1.0.0-beta01 => 1.0.0-beta02
- 2.0.0-beta01 => 2.0.0-beta02
- 1.0.1-beta01 => 1.1.0-beta01
- 1.1.0-beta01 => 1.1.0-beta02
- 1.1.1-beta01 => 1.2.0-beta01
| }); | ||
| }); | ||
|
|
||
| describe('with a fix', () => { |
There was a problem hiding this comment.
In this case:
- 1.0.0-beta01 => 1.0.0-beta02
- 2.0.0-beta01 => 2.0.0-beta02
- 1.0.1-beta01 => 1.0.1-beta02
- 1.1.0-beta01 => 1.1.0-beta02
- 1.1.1-beta01 => 1.1.1-beta01
There was a problem hiding this comment.
- 1.1.1-beta01 => 1.1.1-beta01
This one should be 1.1.1-beta01 => 1.1.1-beta02?
| import {PrereleaseVersioningStrategy} from '../../src/versioning-strategies/prerelease'; | ||
| import {Version} from '../../src/version'; | ||
|
|
||
| describe('PrereleaseVersioningStrategyVersioningStrategy', () => { |
There was a problem hiding this comment.
Also add test for:
- 1.0.0-beta1 => 1.0.0-beta2
- 1.0.0-beta01 => 1.0.0-beta02
- 1.0.0-beta9 => 1.0.0-beta10 (although that would be unfortunate)
- 1.0.0-beta01 => 1.0.0-beta10
There was a problem hiding this comment.
- 1.0.0-beta01 => 1.0.0-beta10
I think this one was intended to be 1.0.0-beta09 => 1.0.0-beta10
There was a problem hiding this comment.
Yup, absolutely. I was clearly not at my best when commenting. Sorry :(
chingor13
force-pushed
the
dotnet-yoshi-versioning
branch
from
66e94df
to
8f20169
Compare
Sorry, I just released a new action version which should contain this update. |
This adds a new versioning strategy that can handle prerelease versioning used by google-cloud-dotnet.
For a
fixtype of release, it will bump the prerelease number and preserve any padded0's.Example:
1.2.3-beta01=>1.2.3-beta021.2.3-beta09=>1.2.3-beta10.