* [B.A.T.M.A.N.] release cycle
@ 2010-06-09 8:12 Marek Lindner
2010-06-09 12:06 ` Sven Eckelmann
0 siblings, 1 reply; 3+ messages in thread
From: Marek Lindner @ 2010-06-09 8:12 UTC (permalink / raw)
To: b.a.t.m.a.n
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [B.A.T.M.A.N.] release cycle
2010-06-09 8:12 [B.A.T.M.A.N.] release cycle Marek Lindner
@ 2010-06-09 12:06 ` Sven Eckelmann
2010-06-10 19:37 ` Simon Wunderlich
0 siblings, 1 reply; 3+ messages in thread
From: Sven Eckelmann @ 2010-06-09 12:06 UTC (permalink / raw)
To: b.a.t.m.a.n; +Cc: Marek Lindner
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [B.A.T.M.A.N.] release cycle
2010-06-09 12:06 ` Sven Eckelmann
@ 2010-06-10 19:37 ` Simon Wunderlich
0 siblings, 0 replies; 3+ messages in thread
From: Simon Wunderlich @ 2010-06-10 19:37 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-06-10 19:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-09 8:12 [B.A.T.M.A.N.] release cycle Marek Lindner
2010-06-09 12:06 ` Sven Eckelmann
2010-06-10 19:37 ` Simon Wunderlich
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).