New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New config flag: snapshot.prereleaseTemplate
, and make snapshot
feature stable
#858
New config flag: snapshot.prereleaseTemplate
, and make snapshot
feature stable
#858
Conversation
🦋 Changeset detectedLatest commit: d046aaa The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
useCalculatedVersionForSnapshots
and use snapshotVersionTemplate
instead
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit d046aaa:
|
re It should still be possible to switch to using a planned version using a boolean config or something.
I don't think we want to drop it just yet - it would be better to raise a warning when it's used. Even though it was an experimental option it is definitely used by some projects.
I didn't look into the code itself but it seems like those are some funky rules here. Wouldn't it be a safe assumption that people are always using I also think that we feel somewhat confident about this feature - it's only a matter of bikeshedding the details and stuff so we should introduce this as a stable option. We don't have to introduce each new thing within the experimental namespace, that is reserved for things that seem useful but for which not everything is clear, has been hashed out, etc |
We use |
Note that this PR doesn't remove the ability to do this - it just accomplishes it in a different way. I agree though that we shouldn't immediately remove the old way of doing this, to allow people to migrate things at their own pace. |
We do have checks for valid semver at a later step if I remember correctly, but I see your point. If only suffix is configurable, I guess it's only a matter of having
With this note added, I guess the solution I suggested above might be ideal? (avoids the semver issues, supports for customizing the snapshot version, and doesn't deprecate/change existing config flags?) If that's the direction you prefer to go, please let me know and I'll update this PR accordingly :) |
I was trying to do something similar in this PR #830 and i realized that - at least for my use case - I would not only like to use simple "templates" with tokens (like in this PR), but also have a new CLI flag allowing to specify snapshot template for that specific run of Anyway, I'm happy to help. |
People have different expectations as to where the tag should be put, some could also want to include both You can also actually attach "random" build metadata (it can be just anything) to your
I'm curious - what's your use case for configuring a template for a specific |
I don't feel that strongly about having the template be the entire version but we would still have to validate the template anyway since you could put in characters that aren't valid as a suffix. We could trivially validate it once by replacing the placeholders with some static values and checking if it's a valid version so what's the harm in making the template be for the whole version?
Yeah, this is why I suggested a template. Having the order of things, the separator and what things should appear in a bunch of separate options just seems confusing, having a template makes it easy to see what it'll actually be. |
If the whole version is the template then this is a valid template: '1.2.3' I don't think we should allow people to tamper with the version itself - it should either be the computed one (our responsibility) or |
If the template is only the suffix, you could make it an empty string and get versions like |
Hm, sure - but with a static suffix, we won't attempt to publish the same version multiple times. It won't do anything useful, it will just skip over the publish step. If we give complete control over the version to users then it will be "easy" to publish Perhaps this is just a territory of "please don't do stupid things" but it seems to me that if we can avoid that then it would be better. The drawback is though that we'd complicate our options API a little bit. I'll leave the decision about this to you - those are just my concerns, I'm not giving a veto to the single template idea. |
Yeah, that's fair, happy to have just a template for the suffix |
Cool, so we'll go with:
So this way, the actual version part is controlled internally (can be customized using Makes sense? @Andarist @mitchellhamilton Please let me know so I'll change this PR accordingly. thanks! |
I think we've agreed on using the template for the suffix itself and I would go with that here, otherwise, we'll end up with people wanting to customize this further. |
Got it, thanks! I'm working on changing this PR :) Will update soon |
Does that mean I won't be able to use both a timestamp and a tag (from the CLI option) at the same time? That would be backwards incompatible with how it currently works. |
Nope, it means that you can still use Here's an example of the config set and their result, does it makes sense? @jakubmazanec
This way, we get the following:
|
@dotansimha Yes, thank you for the explanation. But I would welcome if I could 1) use both timestamp and commit id at the same time, and 2) sometimes reverse location of timestamp/commit and tag. Also, you use Anyway, I was thinking how to then solve the situations like 1) when the tag from CLI option is empty, resulting in invalid preid (e.g.
|
Thanks for the feedback @jakubmazanec !
This might be valid use-case (I never tried to mix the both, but I can understand where it's coming from) - @Andarist @mitchellhamilton what do you think?
Yeah, there is no clear spec in semver about that - you can put whatever you want after the Regarding next steps - I'm fine with both solutions TBH - regarding empty @Andarist @mitchellhamilton @jakubmazanec I guess now it's a matter of a decision? Are we going with a new config param for the suffix (timestamp/commit), or with a template for the entire suffix (tag + timestamp/commit/anything)? |
This |
I vote, of course, for template for the entire suffix (with CLI option to override it). I think it will provide the greatest number of possible prerelease version formats and thus satisfying most users. We can then check if the preid is nonempty (so no
Timestamp is useful because if placed at the beginning of the preid, it solves the prerelease sorting issue. And commit id identifies the commit, that's obviously useful for testing, debugging and stuff. |
@jakubmazanec @Andarist thanks, I'm on it :) What about the default value for @jakubmazanec you mentioned this as |
Good point, we can't introduce such breaking change 🤔 I think the default for |
I agree with @jakubmazanec. It seems the most straightforward to do this. We can't have a single default without some special logic around it anyway, so best to treat the lack of a template in a special way. I will also quote what I've written a couple of days ago here as I feel it's still relevant:
|
snapshotPrereleaseTemplate
to allow customizing the snapshot release versionsnapshot.prereleaseTemplate
to allow customizing the snapshot release version
@dotansimha sorry, I was on a company retreat and didn't have much time to look into GitHub. I've only left a single comment about the breaking change stuff. Otherwise this LGTM. |
…seCalculatedVersionForSnapshots`
snapshot.prereleaseTemplate
to allow customizing the snapshot release versionsnapshot.prereleaseTemplate
, and make snapshot
feature stable
No problem! I pushed a fix to avoid the breaking changes and make the |
Thank you @dotansimha for bearing with me :) The PR LGTM - atm I'm in the middle of things and I would like to merge this with a clear head, gonna take another look at this soon, just double-checking everything etc. If I notice anything to tweak then I will do it myself to avoid the extra cycle of 🏓 I expect this to get merged in within the next 3 days or so. |
Amazing, thank you for taking this one to the finish line @Andarist ! |
Closes #855 and closes #830
Stable
snapshot
featureThis PR changes the stability state of the snapshot feature. You can now use and declare the configuration under the root of
config.json
.Before:
After:
New
snapshotPreidTemplate
Added a new config option:
snapshotPreidTemplate
for customizing the way snapshot release numbers are being composed.Available placeholders
You can use the following placeholders for customizing the snapshot release version:
{tag}
- name of the tag, as specified in--snapshot something
{commit}
- the Git commit ID{timestamp}
- Unix timestamp of the time of the release{datetime}
- date and time of the release (14 characters, for example:20211213000730
)Integration with
useCalculatedVersion
You can still use and pass
snapshot.useCalculatedVersion: boolean
if you wish to have the snapshot releases to based on the planned release of changesets, instead of0.0.0
.Legacy mode
If you are not specifying
snapshot.prereleaseTemplate
, the defualt behaviour will fallback to use the following template:{tag}-{datetime}
, and in cases where tag is empty (--snapshot
with no tag name), it will use{datetime}
only.