[Feature] Canary should have incrementing version numbers.

[cpojer]

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]

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

[cpojer]

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]

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

[marcins]

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]

Bumping this again. This is so broken it hurts.

[Guria]

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]

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]

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]

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

[evocateur]

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

[tdreyno]

Thanks @evocateur, I'll try it out!

[ivosabev]

Same problem with 2.0.0-rc.0

[evocateur]

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]

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

[KyleAMathews]

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

[gaearon]

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]

Oh right. Yeah very little of that in Gatsby so have avoided problems.

…

On Thu, May 18, 2017, 12:55 PM Dan Abramov ***@***.***> wrote: 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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#277 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEVh5JZUz3srZuRIte_N_eapQLiGhH_ks5r7COpgaJpZM4JLG1g> .

[evocateur]

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]

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]

@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]

@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]

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]

The yarn registry is just a proxy for the npm registry, right? This sounds like a yarn client bug.

…

On Feb 27, 2018, at 01:12, Pleun Vanderbauwhede ***@***.***> wrote: 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: ***@***.***%2fapp-2: New versions must be valid semver.". — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[lock]

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.