Re: Next Release Planning

>I am not sure we must have new features in each release, a release of >bug fixes seems also reasonable to me. Why not keep it only time-based >release regardless of commitments for new features for the release. I like giving people good reasons to upgrade, but also good reasons to install the current version - and in terms of communication, if we say that 3.2 will be "3.1, with lots of bug fixes", and that it will be along in 3 months, why would anyone install 3.1? We've just said it's a buggy release that will soon be obsoleted anyway. IMHO, it's better to say "here's what 3.1 does well, here's what 3.2 will be able to do that 3.1 doesn't". I'm not suggesting a revolution with every release, but one thing which is identifiable as "new in 3.2" doesn't seem like a lot to ask.

That said, I have previously worked on a project, where we had one full release cycle whose goal was "make it work better on Linux", and it was a very positive release cycle, lots of new contributors and energy, because it was a goal people cared about. So purely bug-fix & stabilisation releases can work, if you have a measurable goal to compare against. >We can ask what new features are planned/expected to be pushed in the >near future, if we get reply with a lot of features then we can call it >major version (4.0) if we get only minor features we can use a minor >version (3.2, 3.3, etc). I don't care about major/minor versions - I have been in far too many discussions in both GNOME and GIMP on whether a release is "worth" a new major version. Personally, I have a view which is much like that of Queen Victoria towards bathing: I'm happy with incrementing the major version every year or two, whether it's needed or not.

Cheers, Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62 _______________________________________________ Board mailing list Board(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/board