Re: [B.A.T.M.A.N.] release cycle

Sven Eckelmann
2010-06-09T12:06:03Z

[-- Attachment #1: Type: Text/Plain, Size: 6132 bytes --]

Marek Lindner wrote:
> Due to various reasons these minor versions (0.2.1 & 0.2.2) contain much
> more than just bugfixes. Individual features & major changes have been
> backported from the trunk. This has the advantage of adding new features
> faster instead of holding them back for months but on the other hand might
> introduce new bugs at the same time. How to move forward from here ?
[...]
> * To reflect the new & changed nature of the release, the version
> numbering has to change a bit. The following releases (after 0.2.2) will
> look like this: 0.3, 0.4, etc. We thought about adopting the linux
> numbering scheme but it might lead to confusion as you can use a new
> batman with older kernels.
[...]
> Comments ? If nobody objects we would start pretty soon following these
> guidelines.

Personally I don't see why the numbering scheme is useful here. So just sum it
up:
* ~4 releases a year
* continuous flow of features/additions
* no short and precise release goal for version like 1.0 (only something
like "everything should work well")

I would guess that version 1.0 or 2.0 or whatever would not happen in that
evolutionary development model. In that situation I am a big fan of numbering
like YYYY.R.B - YYYY is the year of a "major" release, R number of release in
that year (starting at 0 as we are trve people), B is the number of releases
for that major release (0 for the first release, 1 for the first bugfix
release, 2 for the second bugfix release - this of course only happens when we
would have a stable branch).

This was also in discussion when linux was changed to a more evolutionary
development model with 2.6.xx - the discussion stopped somewhere when somebody
noticed that some build scripts for some important userspace applications used
the linux version number to decide what code paths should be used and that
they could break if the version numbering scheme would be changed. Some
persons started to generate some formulas to convert the YYYY.R.B to something
like (2+Z).(Y%BIRTHDAY_OF_LINUS).XXXX - but i think nothing useful were
generated in that discussion - at least nothing better than nazi analogies.

Linux has also the problem that the version number must be known quite early
(at the beginning of a merge window). So for example the merge window starts
for the fourth release in the year 2011 at the 24. december 2011 and the
release tarballs would get released on 2012-02-29 then it would get the
version number 2011.3.0 (2011 started the merge window; release .0, .1 and .3
already appeared in the year 2011; it is the first release of 2011.3. and so
no bugfix releases until now). When the sixth bugfix release would be released
on 2012-06-23 it would still be called 2011.3.6

So it is maybe a good idea to use also the year when start to develop stuff
for a new release (aka right after a release happens) to have the version
number always well defined during a development phase.

So I see following as benefit:
* It doesn't look like we are something as release goal for 1.0 (aka a big
step forward)
* it doesn't look like it is in some pre release state
* the version numbering scheme should also work in 100 years
* we don't get the release 0.403.0 in 100 years
* version comparison functions of package management systems still works as
it is strict monotone starting from left to compare each part separated
by a dot
* we have already defined a part for the stable releases

Problems I see:
* it is more common for distributions of bigger software packages to use the
year in the version string (texlive for example)
* the YYYY is "huge" compared to the rest of the version string
* /please insert problem you see here/

> * We keep the 3 months release cycle containing new features. All new
> features go into the trunk first and when ready can be staged for the
> upcoming release. This way, we won't have major releases anylonger but
> rather a constant flow of new stuff.

It is still open how the patches in trunk gets prepared for maint? I had also
a smaller discussion with Marek about the problems, but there were no final
decisions.

A small real world example (little bit shortened and changed to explain stuff
better):
* maint is a branch of trunk when we used procfs for all configuration
* trunk gets gw which uses procfs for configuration
* trunk gets patches to change everything from procfs to sysfs
* trunk gets bonding which uses sysfs for configuration
- sysfs patches get backported to maint
* trunk gets patches to change parts of sysfs to debugfs
- debugfs patches gets backported to maint
- gw patches should be ported maint

So all backporting steps are really backporting steps as they cannot easily
applied on maint. Different other patches touched their code and maybe those
are available also in maint and sometimes they are not in maint (sometimes it
is not a merge conflict you see in your version control system, but a conflict
you would see during the compilation or when you try to use it). During that
backporting steps are many possible ways to merge the conflicts. Maybe
somebody adds/removes a newline, changes the order of independent codelines,
does something slightly different in maint as he would have done to create the
same result as we currently have in trunk and after some more iterations trunk
and maint diverged a lot.

This is nothing hypothetical as it already happened in our maint an linux
branch (involved people were Marek, Andrew, me and maybe also somebody else).

A solution would be to use patches rebased by from master on top of maint in
my master-rebase repository. But I must know which patches should be applied
to maint to get it rebased at the top of the rebase branch... and the actual
author must check the patch before it gets applied as I only guarantee that
the end result (when all patches are applied to maint) has the same files
(content-wise) as we have in trunk.

Best regards,
Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]