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