Next Release Planning

[Ryan Harper]

* Dave Neary <dneary at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com