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

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

[Marek Lindner]

Hi,

while sitting in Bracciano (at the WMBv3), enjoying the sun and the excellent 
wine we were thinking about our current release cycle. Since we began merging 
our code into the official linux tree we published a new version roughly every 3 
months to have a compatible batman-adv/batctl version for each linux release. 
For instance:
 * linux 2.6.33 => batman-adv/batctl 0.2.0
 * linux 2.6.34 => batman-adv/batctl 0.2.1
 * linux 2.6.35 => batman-adv/batctl 0.2.2 (to be released soon)

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 ?

After a long and healthy discussion we came to the following proposal:
 * 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.
 * 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.
 * If we find a volunteer to take the job, we would be interested in having a 
   "stable" branch. The maintainer could pick any release of interest, fetch
    stability patches flying around and apply only those to the branch. 

Comments ? If nobody objects we would start pretty soon following these 
guidelines.

Regards,
Marek

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

[Sven Eckelmann]

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

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

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 6665 bytes --]

Hello,

the year numbering scheme would be fine with me, currently i can't think of 
anything which would speak against it and it would represent our evolutional
model quite well. I would vote to apply it.

best regards,
	Simon

On Wed, Jun 09, 2010 at 02:06:03PM +0200, Sven Eckelmann wrote:
> 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: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]