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

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

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