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 releases. 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 around.
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.
Agreed.
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.
Indeed.
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? Duncan