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
Correct way to use conventional-commits and canary / prerelease #1433
Comments
I experienced this behaviour as well. To complement this issue: When running
Expected behaviour
Current behaviour
|
To control the version bump of |
@evocateur That is, unfortunately, not a viable option in independent versioning scheme as the version bump would be different for each package, depending on the contents of individual commits (due to In my opinion, the current behaviour of this flag's combo is unintuitive, at least. It would be best if they could be somehow aware of each other, and if that is not something the project's maintainers are interested in, perhaps the docs could be made a bit more explicit about this...? Thanks! |
Oh, I know. The two flags aren’t meant to interact, and should probably throw an error or at least warn loudly? PRs to improve the documentation are always welcome!
… On May 25, 2018, at 10:11, Robert Rossmann ***@***.***> wrote:
@evocateur That is, unfortunately, not a viable option in independent versioning scheme as the version bump would be different for each package, depending on the contents of individual commits (due to --conventional-commits).
In my opinion, the current behaviour of this flag's combo is unintuitive, at least. It would be best if they could be somehow aware of each other, and if that is not something the project's maintainers are interested in, perhaps the docs could be made a bit more explicit about this...?
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@evocateur What about I know that both the examples I gave above don't do what I would expect and I was just reaching out to see if any folks had a working "process" for releasing a "rc" build while using |
Lerna itself does conventional commits with a preid (beta, right now). Exact should be fine, though not really necessary in my experience.
The major difference between that arrangement and canary is that canary does not make any commits, and conventional commits etc always does. Non-canary is not presently very well-suited for CI publishing, for this reason.
… On May 25, 2018, at 22:49, Gordon Smith ***@***.***> wrote:
@evocateur What about lerna publish --exact --conventional-commits --preid=beta, what is the expected behavior there?
I know that both the examples I gave above don't do what I would expect and I was just reaching out to see if any folks had a working process for releasing a "rc" build while using conventional-commits (I don't mind doing some manual stuff!!!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
The previous comment says Lerna does conventional commits with a preid, but I'm not seeing that. I branched, made a one line change to a single package, and executed
and it bumped the patch for everything dependent on that single package, and it bumped the minor version of the package itself (my commit message was 'feat(scope): message' so that is correct), but there was no pre-release tag of any kind applied to any of those versions. Not 'beta' and not the --preid I specified. I could find nothing in the conventional commits documentation which suggested a mechanism to force a prerelease via the pull request text or anything else, so I can't figure out how to get a pre-release tag on anything, let alone a user-specified one. What am I missing? What I really want is for --preid to be '.' so that multiple pull requests don't result in published version conflicts if they both use the same label. The short git revision should still differentiate the versions. I have a mechanism to pass the git revision into my publish command, but I do need the publish command to actually pay attention to it. At the moment, it does not appear to. Also, the statement by @evocateur that conventional commits always commits changes doesn't seem to be try. When I specify --skip-git, it does exactly what I want. If it also obeyed --preid, it would work exactly as I need it to. I'm not sure what the argument against that is. Why wouldn't someone want to be able to do a pre-release of a package with conventional commits?
That is 100% correct EXCEPT for the missing prerelease suffix on the version numbers. |
It certainly does SEEM like it shouldn't be that difficult to integrate --preid with the conventional commit recommended versions, since it seems like you could just add it as a suffix with a hyphen and call it good, but I'm guessing that there's going to be complexity added if doing a second pre-release publish, since that might end up with -suffix1-suffix2. It's too late in my day to try to unwind all of that logic and figure out the best way to specify the preid such that it actually gets passed to the semver library when the version is incremented, rather than doing a dumb string-append to semver's output, but this seems like it would go a long way toward making CI auto-publish workable. My intended workflow is as follows: Developer submits pull-request to release branch with update.
Developer pushes changes to release branch (merges PR):
Release is approved
For now, I can modify my workflow to build the sandbox versions entirely from local monorepo packages and skip NPM for sandbox testing entirely. But that means I cannot exercise the npm publish process or build service images via npm install until I am pushing a production release to staging, which is a drag, since those things can break, too. It would be MUCH better to be able to specify a pre-release suffix when using conventional commits. |
Lerna itself uses conventional commits with a prerelease preid (beta). You need to specify `--cd-version prerelease`. All the other stuff is way out of scope for lerna.
… On Jun 14, 2018, at 20:32, sgendler-stem ***@***.***> wrote:
It certainly does SEEM like it shouldn't be that difficult to integrate --preid with the conventional commit recommended versions, since it seems like you could just add it as a suffix with a hyphen and call it good, but I'm guessing that there's going to be complexity added if doing a second pre-release publish, since that might end up with -suffix1-suffix2. It's too late in my day to try to unwind all of that logic and figure out the best way to specify the preid such that it actually gets passed to the semver library when the version is incremented, rather than doing a dumb string-append to semver's output, but this seems like it would go a long way toward making CI auto-publish workable.
My intended workflow is as follows:
Developer submits pull-request to release branch with update.
trigger pre-release publish via conventional commits to increment versions correctly, but add a pre-release suffix of label.short_commit_hash.
build docker images of pre-release services which depend on pre-release packages via npm install
push docker image to repo with tag service-version, which is now next {semver}-{label}.{short_commit_hash}
update sandbox infrastructure to run image:{semver}-{label}.{short_hash}
launch integration test image. When it completes successfully, it trips a webhook that merges the pull request (or just approves it).
Developer pushes changes to release branch (merges PR):
trigger release publish via conventional commits to increment versions correctly and publish to npm
build docker images of services, which depend on released packages
push docker image to repo with tag service-version, which is now next {semver}
update staging infrastructure to run image:{semver}
launch integration test image. When it completes successfully, trip a webhook that asks for release approval.
Release is approved
update prod infrastructure to run image:{semver}
For now, I can modify my workflow to build the sandbox versions entirely from local monorepo packages and skip NPM for sandbox testing entirely. But that means I cannot exercise the npm publish process or build service images via npm install until I am pushing a production release to staging, which is a drag, since those things can break, too. It would be MUCH better to be able to specify a pre-release suffix when using conventional commits.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I am experiencing the same issue as @sgendler-stem. Using I've also tried your tip @evocateur without success. running one of these: results in a wrongly bumped version number according to conventional-commits spec (it is always a PATCH). Having |
Basically, an explicit |
Yes, that is what I initially thought, I was just following your tip above my comment. To be more clear, what I really wanted for lerna to do is something like @robertrossmann mentioned. Imagine I have a package at If I kept doing Eventually the release would be ready, and I would just use There's also a chance there's a breaking change while publishing prereleases: If package version is Right now, |
Because conventional commits has no concept of an automatic prerelease. |
@evocateur But if I want to do what @pantoninho has mentioned, what should I do? It seems currently "scripts": {
"devVersion": "yarn lerna version prerelease",
"releaseVersion": "yarn lerna version --conventional-commits"
} I have something like this and want |
The workflow that @pantoninho describes is the correct behavior for combining conventional-commits with prereleases. Lerna should be updated to behave in this way. I also intuitively thought that |
@evocateur maybe I did not explain myself correctly. I need lerna to be able to guess the next version according to conventional commits specification and also add a preid tag on the version. I've found out that on
I am able to contribute but I think I need some guidance first. |
Hmm, is it possible to use the normal logic from conventional commits to determine the expected bump (without preids), and then add the preids on after?
I would like to have CI running automated releases with alpha releases on one branch e.g.
The way it is, if the package was at |
This also leads to the undesireable situation where the type of version bump depends on the history of pre releases. Consider the following two alternative timelines, where the same series of code changes is made, but with different prereleases: Without prereleases 👍
With pre-releases 😕
|
I have also been contemplating on what the correct workflow for Lerna is along with conventional commits and specifically prereleases. My project follows the gitflow workflow, with Things to remember:
When ready for a big release, a My final decision making revolves around how and when to properly bump the versioning, and if it is possible to automate this in Lerna. I came to these 3 cases, where our Case 1:Automated version bumps with conventional commits and a The user can install
Takeaway: Using a dist-tag to identify prereleases instead of a prerelease identifer is less clear to consumers. Versioning of the pkg is also incremented at a faster rate for (not really a con, just a messier versioning flow).
Case 2Publish a prerelease with Lerna and the prerelease identifier The user can install
Takeaway: Using a dist-tag and pre-release identifier to identify prereleases is more obvious to consumers, but the final versioning is a surprise. This also seems to go against the norm of semantic versioning, where it is expected that This seems like the obvious wrong solution.
Case 3A minor release is bumped manually and determined by the developer when creating the
Takeaway: Manually determining the version and using a dist-tag and pre-release identifier to identify prereleases is the most obvious to consumers. The final versioning should not be a surprise. This follows the pattern of semantic versioning, where it is expected that Since we follow the gitflow workflow, it also states:
This seems to be a good solution, but we can't automate the versioning via continuous integration.
ConclusionWith the current way Lerna handles prereleases, we either utilize dist-tags with Lerna publishing to automate everything, or we manually determine the version bump when a release candidate is ready. I'm curious to know if other teams have any solutions towards full automation of bumping versions and publishing releases. @evocateur Also curious if you have any insights or advice for this with your experience in prereleasing versions for Lerna. Thanks everyone! |
@jenniesyip Thanks so much for the detailed analysis! I reopened this issue and added a tag that tells the bot to stay away, sorry about that. I'm a bit busy at work right now, but I hope to circle back by the end of the week. Much food for thought. |
@jenniesyip I raised #1991 to resolve the issues you've laid out, can you read through the OP and let me know if the approach feels in line with your use case? |
@erquhart Sorry for the super late reply (so much work to do!)... this looks amazing so far! 🎉 ❤️ Thank you for your hard work! |
@evocateur @erquhart I'm having a similar issue with Lerna 3.20.2; see my post on Stack Overflow |
@customcommander, did you tried to use flags |
@miszo Hey thanks for your comment but it didn't work. When I run
Then Lerna asks which bump should occur; therefore the conventional commits specification is therefore ignored. When I had |
This worked just fine for me. |
Question
Made the switch to use conventional-commits and am trying to work out the "correct" way to do a beta or rc release. My instinct was to do a:
Or
But neither appear to do what I would expect?
The text was updated successfully, but these errors were encountered: