On Mon, Oct 15, 2012 at 2:11 PM, Phil Elson <pelson....@gmail.com> 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. ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
