Well, if the kernel can do it, I can too
In fact the current numbering schema is inherited from start. It was already changed once in the past from 2.07 to 2.0.7 to make it easier to manage package updates and be more coherent with other software.
But the current evolution was not managed seriously enough I must confess. I tried to keep the 2.2.9 line as stable as possible, but that’s just not possible, and I even included some incompatibilities during its evolution, due to users requests. The last one being the use of a real init in busybox instead of the script we were using since ages which was moved to rcS !! That’s not a minor change so could alone justify the move.
So it’s time to mimic Linus once more and to move on to a hopefully more clear numbering schema:
- 3.0.x will be the next stable (long time support), and it will get incremental update as was 2.2.9.x, but without disruption in functions.
- 3.1.x will be the one after with memory management reviewed, and busybox optional (right now it’s removed, but as a friend suggested it to me, it could valuable to give the choice and keep it around as well
- 4.0.x is now the planned perl rewrite
So expect 3.0.0 not later than next Monday, before leaving for LinuxCon. The bugs I need to handle are those of my HP customers :
- OBDR support for SAS attached DAT (also in #358)
- multipath problems (in #508, #510)
- Some others as described in http://trac.mondorescue.org/query?status=assigned&status=new&status=reopened&group=status&milestone=3.0.0
if I can solve bug #500 and #473 around mdadm format (personal dev), I’ll do. I have looked at it, but it requires modifying some internal structures, and I’m always careful when having to do so. Maybe rather for 3.0.1.