4 Oct
2017
4 Oct
'17
1:28 p.m.
Hi Max,
I asked before and now we have https://gerrit.osmocom.org/4127 so let me ask
again:
What is bumpversion used for in your 'make release' setup?
I would expect version bumping to be a human choice.
How is it intended to work?
~N
4 Oct
4 Oct
1:33 p.m.
It is human choice - you'll have to explicitly call "make release" to get
the version
bumped.
What bumpversion does is helping to automate the boring details of it:
- determine current version (provided it matches the semver spec)
- pick next version number (according to semver spec)
- commit the changes to git
- tag the release commit
More details can be found in bumpversion manual.
On 04.10.2017 13:28, Neels Hofmeyr wrote:
Hi Max,
I asked before and now we have https://gerrit.osmocom.org/4127 so let me ask
again:
What is bumpversion used for in your 'make release' setup?
I would expect version bumping to be a human choice.
How is it intended to work?
~N
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
2:59 p.m.
On Wed, Oct 04, 2017 at 01:33:51PM +0200, Max wrote:
It is human choice - you'll have to explicitly
call "make release" to get the version
bumped.
What bumpversion does is helping to automate the boring details of it:
- determine current version (provided it matches the semver spec)
- pick next version number (according to semver spec)
How does it pick the next version number, i.e. how do I tell it whether to bump
major/minor/patch versions? Ah, I see in "Make a new release" wiki page:
make REL=minor release
Personally, I find it rather trivial to pick a number, which would also allow
manual version skips that we might see necessary for hypothetical reasons. As
in
make REL=2.0.1 release
If we did this, would we still use bumpversion for other tasks?
Semver validation could also be a simple regex.
If it's only us needing that program to make a release that's fine dependency
wise, so far I'm just probing what it is used for.
- commit the changes to git
It's not bumpversion that does the commit though, right. Anyway:
What changes get committed during 'make release':
- does it empty the TODO-RELEASE?
- does it bump LIBVERSION API versions? (probably not, right?)
- does it edit the debian changelog?
- tag the release commit
Ah, so the signed git tag is now done automatically? Also I see on the wiki
page that it may be necessary to re-tag the release after review, anyway. Maybe
tagging the release should not happen automatically? I'd rather not add my
official personal signature to a tag before reviewing. I also may need to pass
a GPG key ID to the tagging to sign with the proper key, I guess it's simpler
and less dangerous to leave it as a manual step...?
What do you think?
Thanks,
~N
P.S.: I'm still meaning to review the release hands-on and adjust the wiki
page, but I'm simply not getting all the things done that need attention at the
moment :/
5:20 p.m.
On 04.10.2017 14:59, Neels Hofmeyr wrote:
Personally, I find it rather trivial to pick a number, which would also allow
manual version skips that we might see necessary for hypothetical reasons.
I don't think we should optimize release automation for hypothetical reasons - rather
for most common use-case. After all, nothing stops us from doing every single step
manually and changing it as necessary.
If we did this, would we still use bumpversion for
other tasks?
We don't have to but I don't see why we should re-implement its functionality in
the
script if it's available already.
It's not bumpversion that does the commit though,
right.
Wrong. It's bumpversion which creates a tag and does commit. It can be done without
it of course, I just don't see any benefit in reimplementing in script what is
available as a tool already.
What changes get committed during 'make
release':
- does it empty the TODO-RELEASE?
Yes. The debian/changelog for libraries is generated from it.
- does it bump LIBVERSION API versions? (probably not,
right?)
Automatizing this would require way more efforts: we'll have to check the API/ABI
changes since last release. So it's not even on the TODO. Feel free to contribute
your ideas as to how this can be done though.
- does it edit the debian changelog?
Yes, this is actually mentioned in
https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release The
changelog is either based on TODO-RELEASE or based on commit log. I really think it
would be worth your time to read through the wiki page - it's not that long (and
partially is written by you anyway ;) and it'll help to clarify some of your
questions right away.
Ah, so the signed git tag is now done automatically?
Again - see https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release
Also I see on the wiki page that it may be necessary
to re-tag the release after review, anyway.
Also, it may be not necessary. I expect that in most of the cases there'll be no need
for that once we sort out the leftovers from previous manual release process
(non-semver versioning, missing entries in debian/changelog, missing release tags
etc). So far I've never needed manual re-tagging when making release on top of older
release made with "make release" - only to fix weird stuff when releasing on top
of
manual releases from before.
Maybe tagging the release should not happen
automatically?
Why?
I'd rather not add my official personal signature
to a tag before reviewing.
Again, why? Everything "make release" does is purely local to your machine.
Nothing
is pushed to the network whatsoever. You can rollback/modify any changes the way you
see fit, and even after that it still will have to go through gerrit.
The "make release" is not intended as replacement for your decisions - it just
automates most common steps which would have to do manually otherwise. And it's way
too easy to forget about some of those as you can see in many of our repos. I think
that's the main benefit actually - not so much in saving you some typing but making
all the necessary changes for release in a single step to make sure we don't
forget/omit something essential.
I also may need to pass
a GPG key ID to the tagging to sign with the proper key, I guess it's simpler
and less dangerous to leave it as a manual step...?
What kind of dangers do you see in automated tagging?
P.S.: I'm still meaning to review the release
hands-on and adjust the wiki
page, but I'm simply not getting all the things done that need attention at the
moment :/
Note: it's still not 100% finished - I plan to add changes for handling library and
non-library from the same repo, but haven't found the time yet.
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
2408
days inactive
2408
days old
3 comments
2 participants
participants (2)
-
Max -
Neels Hofmeyr