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.
On Mon, Oct 15, 2012 at 2:11 PM, Phil Elson <pelson.pub@...149...> 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
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