* Dave Neary <[email protected]> [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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/board -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx [email protected] _______________________________________________ Board mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/board
