release process review

historical

Hi Neels,

thanks for getting this discussion going.

On Sun, Sep 03, 2017 at 05:39:12AM +0200, Neels Hofmeyr wrote:

> (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*.

Full ACK.

> 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".

ACK.

> > 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.

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.

> 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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)