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

Simon Wunderlich
2010-06-10T19:37:52Z

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