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.
* 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
* 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