-
Notifications
You must be signed in to change notification settings - Fork 36
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
Flagged prerelease bump fix #97
Flagged prerelease bump fix #97
Conversation
@antongolub - I have opened this new PR with a flagged changed and will close my old one. Please let me know if you have any further concerns. Thanks! |
Could you refer the new flag in |
* If you have a legacy fix where you are doing a work around and need the old behavior, please add useTagsForBump to config
295951f
to
be24206
Compare
@antongolub - Sorry about the slow turn around on this. I updated the flags under the same commit. I did realize that I hadn't written or used the correct naming for a boolean flag so I changed to Thanks for your patience! |
No rush required. Can we use the one param name for the entire flow?
|
Just to clarify, are you asking for us to update the switch to deps.tags? and then push that through the pipeline? (Another note here, is that we never used the tags for stable release bumps, only prerelease. Hence the bug not being so pronounced, so I'm not sure we want to get the indication that "tags" is a simple mode. Secondly, it looks like you're asking for that to default to true. I would push back on that request if it wasn't just an example. When I wrote the tests for multi-semantic release, I simulated the bug in an existing test because I found out that the tests weren't actually letting the tags get added due to a try-catch. Once that was fixed, the test was failing. Because of that, this is definitely a bug fix so I would make the fix opt-out. I do agree that the flag should be provided as an escape hatch for anyone with their own customized work arounds. Let me know your thoughts and I'll get them swapped. |
I'm just speculating about what this fix will look like a half year later) I confess that perhaps I do not fully understand the current impl, and I believe you've figured it out better than me, so if you say both ´use*´ and Thanks for you patience and efforts. |
Thanks for the clarification! I have a welding class tonight but will try to get this finished tomorrow. To your point about use and skip, I'm pretty sure I just got lazy due to the iterations. I can clean that up so it will be standard. |
@antongolub - It should be all there now. We are just using |
We're at the finish line. I renamed the new param to |
@antongolub - sounds good by me. Merge whenever you'd like! |
🎉 This PR is included in version 7.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
New PR
This is a new PR since it fundamentally changes the branch I already merged to my fork.
The Changes address this comment about flagging the old bugged behavior so old users have a way to sustain any of their work arounds. #96 (comment)
Fixes Issue 75
On Extensive debugging, the prerelease "next" logic that we use for bumping dependencies is disregarding the "_lastRelease" on a package and biasing on the git tags. This is an issue though, because we always end up having run the previous package's release thanks to the topo library, so there is a tag indicating the current release. Our desired release is this tag though and not the next increment. It is, however, the desired bump of the "_lastRelease" of that package.
Changes
To fix this, we keep a light touch by augmenting getNextPreVersion to:
pkg.dir
(they would try catch the failed tag retrieval)
skipEvaluateTags
:The flag and README are updating since there is a path where users of this library may have already provided work arounds based off of the behavior. It is opt-in though, so that other users do not get the bugged behavior on new usage.