On Sat, Jul 19, 2008 at 8:02 PM, Eric Firing <[EMAIL PROTECTED]> wrote:
> We might want to consider, however, whether such extensive changes > should be made immediately *before* a "bugfix" release. I think John is > trying to get one out. I am already a little nervous about other recent > and impending changes in this context. (Your idea of a branch was a Although I may have used the phrase "bugfix release" many times in the past, I want to clarify my thinking on this. I distinguish between point releases and major releases. With the exception of the maintenance branch, on which the *only* changes should be bugfixes, I expect every point release to have new features and bugfixes. When we decide to bump the major version is of course subjective, but it normally comes when a number of significant features have been introduced, and it should be comparatively rare, 2 to 4 times a year or so. But I expect and want new features in every point release. We are fortunate that we have a lot of developers, and Charlie is a very responsive release manager. I would rather err on the side of getting new features out, tested to the best of our abilities, with the understanding that if we break something important we will roll out a point release that fixes a critical bug within 12 to 24 hours, and hide the broken release in the mean time. Release early, release often. My aversion to branches stems not from the weaknesses in svn merge, which may be better in hg or other version control systems. The reason I wnat people contributing to the trunk is that I want as many people testing and using the code as possible so we can find and fix the bugs before they are released. While Michael's transforms refactoring was so significant that it absolutely required a branch, we did not start finding the bugs until we made his branch the trunk, and even then did not find the bulk of them. We found them when we released the code. More tests will help, and we should have as many tests as we can muster, but until we have bullet-proof tests we have to leverage our developers and users as testers. The only short term pressure for a point release is coming from debian, because they are having some trouble with our last point release. Because debian is an important platform, I want to get a point release out that satisfies their problems ASAP, but not before we are ready. Whether this is next week or next month or next year will depend on whether the code is ready (I hear echos of Orson Welles in the old Paul Masson commercial, "We will sell no wine, before it's time"). In the case of the contouring enhancements, they're not ready, so we'll wait. In the situation where debian or some other important vendor has a freeze deadline with a critical problem that needs fixing, we can always do a branch off the last point release that fixes just the required bugs. Sandro can keep us appraised if such a deadline is approaching for 0.98.2. JDH ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
