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
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
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
b.a.t.m.a.n@lists.open-mesh.org
-
Marek Lindner -
Simon Wunderlich -
Sven Eckelmann