[matplotlib-devel] 1.3+ Release schedule (was: strategy for 1.2.x, master, PEP8 changes)

[Todd <tod...@gm...>]

On Mon, Oct 15, 2012 at 2:11 PM, Phil Elson <pel...@gm...> wrote:
>> if we leave PEP8 out of v1.2.x, and decide that once it is released,
>> v1.2.x will be changed
>> only if critical bugs are found, requiring a v1.2.1 release
>
> I agree. I think it is important here to be very clear about what
> constitutes a "critical bug". In my opinion, releasing a v1.2.1 would be a
> very last resort and I would sooner see us move forward by fixing bugs in a
> new feature release (1.3). In order to do this we should have a schedule for
> our next release *now*, and ideally it shouldn't be that far away (i.e. no
> longer than 8-9 months). Some of my reasons for this assertion include:
>
> We have an amazing community of people who help us build our release bundles
> - so the actual release deployment mechanisms are no longer a limiting
> factor
> We have a long period between identification of features, their
> implementation and then seeing those features available in the latest
> release to our users. I would love to see that time shorten to share some of
> the cool new features that are being developed with non-developers sooner so
> that we can get feedback and go through the development cycle quicker.
> Currently making a release is a massive task which takes many developers out
> of actually being able to focus on new features or bugfixes. Having a
> quicker release cycle should mean we have fewer large changes per release
> and reduce the need we currently have to squeeze as much as we can into the
> next release - ultimately I think it will mean that we need to expend fewer
> developer hours focused on release management and last minute code
> reviewing.
>
>  [snip]
>
> Phil

Why 8 to 9 months? This still seems like a very long time for a
project of this size. Much larger and more complicated projects
(gnome, KDE, Ubuntu) manage a 6 month release cycle, and for projects
this size I follow 2 to 3 months seems more typical. It's there a
reason the release cycle needs to be so long?

With a few month release schedule you can probably manage just 2 betas
and an rc, judging by other projects.

Also, have you considered a "master is always stable" approach, where
branches are only merged when they are complete? This could make
arbitrary release points much easier.

So basically, rather than waiting until you have a lot done for a new
release, you could have an approach more like Firefox now where each
release just had a couple new features, or maybe even just one big
feature.  Then a very quick beta cycle, and bugfix releases when
needed, but with that quick of a release cycle bugfix releases should
not be as important as they are now.  Other features would be worked
on in parallel in their own branch, ignoring the release entirely.