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

[Sven Eckelmann <sven.eckelmann@gmx.de>]

[-- 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 --]