Skip to content
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

[Feature] Canary should have incrementing version numbers. #277

Closed
cpojer opened this issue Jul 13, 2016 · 24 comments · Fixed by JetBrains/ring-ui#355
Closed

[Feature] Canary should have incrementing version numbers. #277

cpojer opened this issue Jul 13, 2016 · 24 comments · Fixed by JetBrains/ring-ui#355
Assignees
Milestone

Comments

@cpojer
Copy link
Contributor

@cpojer cpojer commented Jul 13, 2016

The canary feature is fantastic, however because it uses commit hashes instead of numbers, publishing a canary release with the same basic version number might require the wrong versions when using ^ for all the other package dependencies. Can we either overwrite the dependencies to require explicit canary versions OR properly version canaries so that newer canaries will always be installed over older ones? :)

@hzoo
Copy link
Member

@hzoo hzoo commented Jul 13, 2016

Ah good point.. didn't really think of that at the time..

@cpojer
Copy link
Contributor Author

@cpojer cpojer commented Jul 13, 2016

Canary is super useful btw.

Also, it would be nice if I could select the next version. Right now it uses lerna.json which is the current version but I'd prefer to publish a canary for the next minor or patch release most of the time, so I have to manually edit lerna.json.

@jamiebuilds
Copy link
Contributor

@jamiebuilds jamiebuilds commented Jul 13, 2016

Can we just follow the normal prompting for versions flow for canary?

@marcins
Copy link

@marcins marcins commented Oct 5, 2016

I just ran into this issue, where the "latest" version of a dep was chosen over the canary because the canary version was based on the last released version number not the "next" one.

If you're automatically building a canary from CI you don't want the prompting flow, so as long as there's still a way to publish a canary with the "next" version number without interactivity then that'd work for my use case.

@tdreyno
Copy link

@tdreyno tdreyno commented Nov 4, 2016

Bumping this again. This is so broken it hurts.

@jamiebuilds jamiebuilds changed the title Canary should have incrementing version numbers. [Feature] Canary should have incrementing version numbers. Nov 16, 2016
@Guria
Copy link

@Guria Guria commented Nov 28, 2016

We should either use incrementing part in canary version before hash, or substitute exact version for controlled packages without caret in front.
Now our canary builds are definetely broken, because users will get wrong dependencies versions :(

@L8D
Copy link
Contributor

@L8D L8D commented Dec 2, 2016

Can we please at least add a flag for using exact versions in published packages? It would even be useful for non-canary releases.

@KyleAMathews
Copy link

@KyleAMathews KyleAMathews commented Jan 22, 2017

Is there anything holding up a PR fixing these issues? I haven't looked at the Lerna codebase much but would be happy to make a PR a) supporting incrementing number releases and b) add support for specifying a next version.

I'm using Lerna + canary releases to great effect with Gatsby and am planning on automating canary releases on build passes (anyone doing this btw?) and these two changes would make that much nicer.

@tdreyno
Copy link

@tdreyno tdreyno commented Feb 10, 2017

@KyleAMathews That'd be great. I hacked it in to my local build: https://github.com/tdreyno/lerna/commit/5f743ca6e347347d6ebf477017f6cebc992c99f7

@evocateur
Copy link
Member

@evocateur evocateur commented Feb 10, 2017

@tdreyno I'd say #426 covers your hacked-in change, since beta 33.

@tdreyno
Copy link

@tdreyno tdreyno commented Feb 14, 2017

Thanks @evocateur, I'll try it out!

@ivosabev
Copy link

@ivosabev ivosabev commented Apr 12, 2017

Same problem with 2.0.0-rc.0

@evocateur
Copy link
Member

@evocateur evocateur commented Apr 12, 2017

Correct, v2.0.0-rc.1 does not properly increment canary versions yet. With annotated git tags, we have a much more useful git describe --long, though.

@gaearon
Copy link

@gaearon gaearon commented May 18, 2017

Just broke Create React App beta releases with this 😢
Is there anything holding us back from enabling the hidden --exact flag for --canary?

@KyleAMathews
Copy link

@KyleAMathews KyleAMathews commented May 18, 2017

For Gatsby I've been telling testers to just use "canary" for their package version.

@gaearon
Copy link

@gaearon gaearon commented May 18, 2017

That doesn’t solve the issue with monorepos since two canaries that depend on each other without exact flag will break as soon as the next hash is higher on alphabetic order.

@KyleAMathews
Copy link

@KyleAMathews KyleAMathews commented May 18, 2017

@evocateur
Copy link
Member

@evocateur evocateur commented May 18, 2017

I was hoping to get around to proper incrementing with better git describe metadata, but implicit --exact sounds like a decent workaround for the time being.

@shawnbot
Copy link
Contributor

@shawnbot shawnbot commented Jul 11, 2017

Somewhat related, as reported in #915: --canary and --cd-version don't interact the way I expected them to. I think that if --canary --cd-version=patch didn't drop the meta suffix (-alpha.x) it might help with this issue.

@alan-agius4
Copy link
Contributor

@alan-agius4 alan-agius4 commented Jan 18, 2018

@evocateur I don't know the whole flow around the --canary and why it uses the commit hash but wouldn't it make sense in order to avoid such issue to use Date.now() instead? as a version. it's always incremental and could avoid collision issues.

@evocateur
Copy link
Member

@evocateur evocateur commented Jan 18, 2018

@alan-agius4 Date.now() gives no authoritative information on the state of the tree when the publish was made. The hash is really intended as build metadata (and thus should be after the prerelease id and other dot-separated stuff, e.g. 1.0.4-alpha.0+deadbeef).

However, until we restore the gitHead property that normally appears in the package tarball's package.json after a "normal" npm publish, we need to keep it there to provide a breadcrumb back to the exact state that the canary version was published from. (gitHead is missing because .git isn't in process.cwd() when we run npm publish from lerna)

@pleunv
Copy link

@pleunv pleunv commented Feb 27, 2018

I'm very interested in getting this to work as currently our desired CI release flow cannot be covered with lerna. However, after playing around a bit I noticed that both 1.0.4-alpha.0+deadbeef and 1.0.4-alpha.0+sha.deadbeef are currently not accepted by the yarn registry.

Command failed: yarn publish --new-version 2.0.1-build.1519722155+61bd02c2 --tag test
warning package.json: No license field
warning package.json: No license field
error An unexpected error occurred: "https://registry.yarnpkg.com/@company%2fapp-2: New versions must be valid semver.".

According to https://semver.org/#spec-item-10 they definitely are valid semver versions.

npm publish will go ahead and succeed, but will strip all additional meta (everything behind the +) from the published package's version.

@evocateur
Copy link
Member

@evocateur evocateur commented Feb 27, 2018

evocateur added a commit that referenced this issue Jul 27, 2018
BREAKING CHANGE:
* `--preid` now defaults to "alpha" during prereleases:

  The previous default for this option was undefined, which led to an awkward "1.0.1-0" result when passed to `semver.inc()`.

  The new default "alpha" yields a much more useful "1.0.1-alpha.0" result. Any previous prerelease ID will be preserved, just as it was before.

* `--no-verify` is no longer passed to `git commit` by default, but controlled by the new `--commit-hooks` option:

  The previous behavior was too overzealous, and the new option operates exactly like the corresponding [npm version](https://docs.npmjs.com/cli/version#commit-hooks) option of the same name.

  As long as your pre-commit hooks are properly scoped to ignore changes in package.json files, this change should not affect you. If that is not the case, you may pass `--no-commit-hooks` to restore the previous behavior.

Fixes #277
Fixes #936
Fixes #956
Fixes #961
Fixes #1056
Fixes #1118
Fixes #1385
Fixes #1483
Fixes #1494
nicolo-ribaudo pushed a commit to babel/lerna that referenced this issue Dec 18, 2018
BREAKING CHANGE:
* `--preid` now defaults to "alpha" during prereleases:

  The previous default for this option was undefined, which led to an awkward "1.0.1-0" result when passed to `semver.inc()`.

  The new default "alpha" yields a much more useful "1.0.1-alpha.0" result. Any previous prerelease ID will be preserved, just as it was before.

* `--no-verify` is no longer passed to `git commit` by default, but controlled by the new `--commit-hooks` option:

  The previous behavior was too overzealous, and the new option operates exactly like the corresponding [npm version](https://docs.npmjs.com/cli/version#commit-hooks) option of the same name.

  As long as your pre-commit hooks are properly scoped to ignore changes in package.json files, this change should not affect you. If that is not the case, you may pass `--no-commit-hooks` to restore the previous behavior.

Fixes lerna#277
Fixes lerna#936
Fixes lerna#956
Fixes lerna#961
Fixes lerna#1056
Fixes lerna#1118
Fixes lerna#1385
Fixes lerna#1483
Fixes lerna#1494
@lock
Copy link

@lock lock bot commented Dec 27, 2018

This thread has been automatically locked because there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Dec 27, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.