On 21/08/12 17:01, Ryan Harper wrote: > * 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.
I agree we want something new, the question is what is the release criteria. If I understand the above suggestion correctly If there are not enough new features we won't release in 3 months? I think this is a mistake because there are hundreds of bug fixes pushed into the repository and releasing a more stable version IMO has great value. For example in Networking we fixed one feature and will probably add one small feature by November, but I know that networking in 3.1 release is very buggy while if you take latest from upstream it is dramatically better, regardless of the features there is a value for releasing in November. > > 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 > _______________________________________________ Board mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/board
