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