-
Notifications
You must be signed in to change notification settings - Fork 12
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
Introduce bump.sh
script to automate version bumping
#27
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your work!
checkout on main and switch to a new branch I'm not quite convinced of that part, I would like your opinion
What's your problem about this? It looks good to me 🤔
I have several points I want to discuss:
- Where do you actually bump the version? Like where are you changing the version in the package.json
- Maybe switching back to the original branch at the end could be nice
- Do we need to merge manually the pushed branch at the end
- A little doc on README would be nice! At least saying this feature is available and add the corresponding files to the tree
I will try the script after your answer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well the script looks great!
hard to tell if there is a bug without testing, but great work 💪
i've got generatlly the same questions as @atxr, and did add some more of them and as well as some remarks and suggestions
i think the script works fine as it is, so i do not require changes nor approve explicitely 👌
Thanks for the review to both of you @atxr and @amtoine !!
The git checkout origin/main
git switch -c tmp
npm version major
OR
npm version 1.5.3
git show
Actually I could, but even if I log the script actions it would be a little too "hiding" to me 😕 I prefer to let the user on the new branch to force it to see the new changes, can also be useful in case the push fails!
Yes and that's intended, no one should have the right to directly push to main, but you'll see that I push on the
You're right I'll add this (you can even open a thread review to force me to do so before the merge! (because the merge is blocked while there are still opened review threads)) I hope that answer your questions! @amtoine I'm answering your remarks soon! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some little changes requested here
Also, can you just add an example of the command to run in the wiki to bump the version?
…sh.sh Fix typo Make postversion_push.sh executable Fix postversion_push.sh
Here I come with the last version of the scrip I hope! Changelog:
The last changes to be done now is I think coloring the logs and maybe refactoring the code! (even if I think it is pretty linear so functions may not help much) |
maybe the PR should have been a draft 'till that point, right? 😕 don't get me wrong, the PR is fine and the changelog looks cool 😉 EDITthese changes precisely address my thread right? 👀 if the thread and the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the last changes look fine 👌
still waiting for my thread to be closed and i'll approve the changes 👌
the changelog
git diff 8a95601..d681cf5
Ahaah absolutely! But you figured it out so that's fine! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all of this looks good to me 😋
Resolve README.md conflicts and package.json
i see that, makes sense 👌
yeaaah 😋 i think rebasing is the best when working on personal branches, i.e. branches only one person works on let's wait for the remaining reviews 😋 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All my threads all resolved!
And the script is quite clean now!
Ready to merge 🚀
last thing, do we wait for @Turtyo? 🤔 |
Context:
#19 brought the first version bump for the iScsc website. However, this one was achieved manually as described in the wiki page but this procedure wasn't expected to last long.
Problem:
The version bump, even if its procedure should be described, shouldn't be achieved manually.
Solution:
I then looked for automatic tools to bump version of software and especially JS, node.js and website software.
I found:
python
npm
native so very interestingSo I first went with
npm-version
because it seems like the more reliable and simple, and I built ash
script around it.Script details:
The script takes one argument which is the new version and apply it to
package.json
,frontend/package.json
andbackend/package.json
.The script will in order:
semver
(fromnpm
),npm
,git
main
and switch to a new branch I'm not quite convinced of that part, I would like your opinionnpm install
to update the*-lock.json
sfrontend
andbackend
together then commit and tag root separatelyIt partially relies on
package.json
script
s to do this job as well asnpm version
!Caveats, Limitations and Testing:
Currently the script is safe, I think, I tried to write it without assuming anything about the user current project state but you may find some mistakes 😕
I must say that the output isn't the clearer you ever saw but it does the job.
You can't fully test it right now, because it will checkout on main and then don't have the right
package.json
s scripts state (it won't commit and output an error because of this when bumping root).It has a "dry run" mode to test it without touching the user's repo: try
DRY_RUN=foo ./bump 0.1.1
What's next?
I don't think that this script will stays as it is for long, right after finishing to write this PR I'll go try
release-it
, but this is a first step!