-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[Case Study] Managing releases with version --deferred #381
Comments
This is actually what I had in mind. For example, taking the Yarn repository as example, everytime I create a new release a workflow runs that will run
The idea is that you don't want to release for every commit, especially if you're working on a big project - if you were, then I'd agree that it would be problematic to double the number of commits. Instead, the idea is that every time you want to "commit" your packages and release them all to the registries, that's when you run
That shouldn't be the case - is it also the case on master? I merged a few fixes related to that yesterday evening. |
Sure but that's just not what I want. We get frequent requests about when which bugfix will be released and I don't want to bother with this anymore. Being able to just refer to canary releases (especially automated ones) is one less release-related issue I have to worry about. The other solution is to just release it as stable but this gets really spammy to the point of multiple releases a day. If you don't want to support automated releases then that's fine. It's a package manager after all and not a release manager. In the end it's probably not that hard to take the version in But that reminds me of another issue: Say I do commit applied versions then I now have to apply different
I can check. |
There will be a sort problem with the nonce because a later release may have a lower nonce. Similarly, hashes don't play well because they are compared lexically. The best would probably be the depth in the
Yep - the
The
|
Just checked the spec again and you're correct. pre-release is considered when comparing precedence. Still not sure having the canary version in version control is viable. The amount of merge conflicts likely dwarfs the usefulness of having CD handled by yarn.
Works on master with Nit: index d45fc560..3c347955 100644
--- a/packages/acceptance-tests/pkg-tests-specs/sources/commands/version.test.js
+++ b/packages/acceptance-tests/pkg-tests-specs/sources/commands/version.test.js
@@ -4,7 +4,7 @@ const {
} = require('pkg-tests-core');
describe(`Commands`, () => {
- describe(`version check`, () => {
+ describe(`version`, () => {
test(
`it shouldn't work if the strategy isn't semver and there is no prior version`,
makeTemporaryEnv({}, async ({path, run, source}) => { I think |
Closing this issue for now, feel free to open a new one when you have other feedback! Also note I've implemented |
Disclaimer: I might read more into
yarn version
than it should be used for.Possibly duplicate of #326
What package is covered by this investigations?
Whatever package is responsible for
yarn version
Describe the goal of the investigation
Releasing canaries from master with only using the
yarn
CLIInvestigation
As far as I understood the documentation the following workflow should be used
This would only result in a single version being published since
yarn version prepatch --deferred
only updated thenonce
which is not part of the version string.Currently CD would have to commit changes applied to the repository so that subsequent PRs would create a new version. This is not viable since it a) defeats the purpose of deferred b) doubles to commits on master (noise) and c) requires every PR to be up-to-date with
master
which doesn't scale to big repositories.The simplest solution would probably include the nonce in the version string for release candidates. Though I'd need to check if semver ranges apply which could cause issues though you shouldn't use ranges for canaries anyway IMO.
Another problem is that
yarn version
downgrades:I would also abuse
yarn version patch
to upgrade release candidates to stable releases:0.0.1-0 -> 0.0.1
0.1.0-0 -> 0.1.0
1.0.0-0 -> 1.0.0
Not sure if this is expected or if there (should) exists a command.
The text was updated successfully, but these errors were encountered: