Using repo to make 'regular' releases

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Mon Apr 24 11:26:20 UTC 2017


Hi Holger,

On Mon, Apr 24, 2017 at 11:45:34AM +0200, Holger Freyther wrote:
> > I would still suggest that the "release" tags should also be made in all
> > the individual repositories.  Otherwise, while looking at git history in
> > an individual repository during development/review, it is not obvious
> > which patches are in which release or not.
> 
> I would like to be lazy but if the have pending SO_VERSION bumps we need
> to make a proper release (bump the version, update the debian package).
> Maybe to make it a bit more easy drop a version scheme like v1.2.3 and
> have a strictly monotonic increasing number like used for systemd/udev
> (and then still have v123.X for minor releases) or the date approach I
> mentioned before.

I don't mind what structure the actual version numbers take.

> > So if at all, I believe 'repo' should refer to tags inside the
> > inidvidual repositories [not sure at possible], or the
> > repository-individual tags should be auto-generated in the same process
> > when generating a new xml file in repo.
> 
> If we go for date as version number we should be able to automate most
> of it and assist where manual work is needed (e.g. work on the TODO-RELEASE).

As indicated, the important part for me is to have tags in the
individual repositories, and then use those tagged versions in the repo
manifest.  Beyond that, I'm open to whatever you guys think makes sense.

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



More information about the OpenBSC mailing list