3 Sep
2017
3 Sep
'17
10:47 a.m.
Hi Neels,
thanks for getting this discussion going.
On Sun, Sep 03, 2017 at 05:39:12AM +0200, Neels Hofmeyr wrote:
Full ACK.
ACK.
ACK. Yes, so one could say "if we already bump the major version
[libversion], we can at that time optionally remove deprecated functions
if we think it significantly simplifies maintenance.
(So far I understood the wiki page "Make a new
release" referring to only these
individual git repository versions, but we must clarify the two different
concepts on that page and at least refer to a package feed wiki page.)
We should make sure not call anything "release" which is not an "osmocom
release" i.e. what oyu called the global package feeds such as
"OsmocomCellNet-17.12" which is the "17.12 release". We should find
different wording for what the wiki page by Max describes in terms of
"tagging a new version in a single repository".
To avoid confusion, rather than talking of
"release" it could help to talk of
"package feed" versus "git version tag".
See my comment above. We should not talk about a "release" in any other
context than the time-based global ones.
master branch
is expected to depend on latest master branches of depended-upon projects
The master branch HEADs are in constant flux, the requirement that each master
works with the other latest masters is more of a daily development requirement
enforced by our gerrit +V builds. For feeds and tags, we should not even
mention "master branch" anywhere. Rather, the entire process *must* refer to
specific version tags *everywhere*. But I'm not entirely sure how to put it. It is
possible that we already have
libosmo-foo 1.2.3 out, but osmo-bar also still builds fine with libosmo-foo
1.2.1.
I guess all we need is that configure.ac version requirements are accurate. We
will not always have to depend on the latest version number that's out, and if
older ones work, ./configure should *not* require the most recent version.
How to verify? I guess a version tag of osmo-X must verify
- that building with the precise minimal versions requested in configure.ac
works
AND
- that building with the currently latest tagged version of each depended-upon
project also works
AND
- that building with each intermittent version of each dependency also works???
Full ACK.
That's turning out rather complex ... maybe
verifying with only the oldest
required and the latest tagged versions is enough?
Fine with me, but given that we only want to release once every three
months, I think a longer build job that iterates over a handful of
package versions is not unfeasible. But certainly not the highest
priority.
make release
of depended-upon projects if necessary before making non-library project release
So, are you saying, if foo needs bar which needs baz, releasing foo requires
also releasing bar, in turn needing a release of baz first?
... "if necessary" :)
To spell it out: this is not necessarily required; only when foo is using new
API of bar that is not available in a tagged version of bar yet are we forced
to make a version tag of bar and depend on it.
BTW, this is implicit by "it must build with the version requested by
configure.ac". Deprecation
policy
I think we should never remove deprecated functions unless it would cause us
inhumane pain to still include them. Dropping them would require a major
version bump. Finally, I tried to call 'make release' but
face these problems:
▶ make release
/bin/bash: bumpversion: command not found
▶ apt-cache search bumpversion
(no results)
Though I find 'bumpversion' on packages.debian.org, I am unable to install it
with 'apt-get'.
https://packages.debian.org/buster/bumpversion
It says "Packages / buster (testing) / devel / bumpversion"
...do I need to add "devel" to my apt sources somehow?
Do we really need bumpversion? Can I instead bump the version manually?
I was also seriously surprised that we introduce a dependency that is
not even available in all our supported distributions. In order to fix
the fall-out from the related changes, I had to add a 'bumpversion'
package build to the OBS for the nightly builds.
Hence I would also be very happy if we can see that dependency go again.
I don't like the tendency to add more dependencies to external packages
everywhere without a *very* strong reason. Whether it's bumpversion or
gnulib or anything else like that.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)