11:34 a.m.
On 21/08/12 17:01, Ryan Harper wrote:
* Dave Neary <dneary(a)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.
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
> Board(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board