Platform policy question: API compatability in minor releases

Duncan Coutts duncan.coutts at
Sun May 10 15:42:42 EDT 2009

On Sun, 2009-05-10 at 01:18 -0400, wren ng thornton wrote:
> Duncan Coutts wrote:
> > So by arguing for new features in minor releases we're saying we should
> > have a 4-6 week cycle. New library features every 6 weeks.
> Thanks for putting some numbers on that. (and, yikes! I'm convinced. I 
> was under the impression that there'd be fewer minor releases than that.)

Sorry, this is a bit backwards, see the other note we just posted. If we
all agreed that we should have new features in minor releases then I
strongly suspect that we would not want such releases on such a rapid
cycle as 4-6 weeks. That only really makes sense for small bug-fix only

As we say in the other email, we should first decide what we want from
releases and then pick major/minor cycles to fit, and not the other way

> > Now perhaps 12 months is too long (I think it is). Perhaps 6 months is
> > too long even (though many other groups have settled on 6 months). But
> > surely 6 weeks is far too short. That means essentially no
> > synchronisation effect at all.
> > 
> > If the majority opinion is that 6 months is too long to wait for new
> > features, then how about 4 months, or even 3? Do people see the point
> > I'm trying to make about the value of synchronisation?
> I think that, given the rate of change in the Haskell world, 12 months 
> is far too long. And I agree that a big part of the platform should be 
> to provide synchronization, for which 6 weeks isn't enough.


> In choosing between 3, 4, or 6 months (for 4, 3, and 2 times per year) I 
> think there's a balance that needs to be struck for the platform to be 
> useful to users. If updates are too few and too far between (as has 
> historically been the case), then active  users will update the packages 
> individually, thus defeating the point of the platform. On the other 
> side of things, synchronicity.


> Of those three options, I think 4 months is probably ideal. Quarterly 
> releases still don't give much time for synchronization. For stable 
> packages (like are currently included) development is slower in terms of 
> API changes, so 6 months may suffice, but if younger packages are added 
> then I don't think biannual releases will allow the HP to track 
> development closely enough.

Yes, one suggestion is that we start with a 4 month cycle and perhaps
review it after 12 or 16 months to see if that pace is right for the
longer term.

> I still think that it would be good to try to have a three stage model 
> for releases, instead of the two stage model that seems to be assumed. 
> Adding new packages or destructive API changes strike me as being very 
> different from compatible API changes (which are, in turn, separate from 
> big fixes and bundling fixes). I'd like to see these two types of 
> changes being distinguished in terms of the release schedule.

I have to say this isn't something I'd thought of. Tell us more. What
would this look like? Would it be something like eg only one release per
year is allowed to make breaking changes?


More information about the Libraries mailing list