
* Dave Neary <dneary@redhat.com> [2012-08-21 08:42]:
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.
Definitely agree with this approach. We always want something new for the next release. It's probably worth keeping a list of features from each of the sub-projects as a potential next-release feature list. And with a defined release cycle, we can see which features will make the cut prior to a feature-freeze date. IMHO, one of our challenges is actually enumerating all of the potential features. I think there are lots of features under development, but I don't think we're collecting all of that info in a single place where you can get a view of potential features in the various sub-projects.
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.
+1
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
-- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com