Platform policy question: API compatability in minor releases

[Duncan Coutts]

On Thu, 2009-05-14 at 23:09 -0400, wren ng thornton wrote:

> > The argument you're making is that API compatible changes are so much
> > less disruptive that it's ok to have them more frequently.
> > 
> > I claim that's not really true. I claim that the synchronization is just
> > as much about API additions as breakage. It's about stability. Users
> > want to know which packages they should have to be able to run most
> > Haskell code. Developers want to know what packages most users have got
> > so they can make their code work with those versions. We can improve
> > these periods of stability without reducing the pace of development by
> > compressing changes into major releases rather than spreading them out.
> 
> Perhaps we should agree to disagree.

I expect so.

> Certainly additions can cause breakage

But that's not what I'm saying. Even additions that cause no breakage
fragment the userbase. Half the users will have version X and half will
have X+compatible-extras and now developers have to decide if it's ok to
take advantage of the new features and exclude half the users. The users
then also feel much more pressure to upgrade which puts pressure on the
distros to do the same. 

The point is, feature releases do turn into major releases. So we cannot
pretend we're having say a 6 month cycle if we've also got feature
releases in between.

> Whether this belief or your belief will be more correct depends, IMHO, 
> on many factors that cannot be known without trying them. I, at least, 
> do not think we have the information necessary to make *accurate* 
> predictions about the stability/relevance of any particular approach. 
> (Perhaps Don could provide an analysis of the frequency of API additions 
> vs API breakages on Hackage?) I have a good deal of experience with 
> F/OSS communities, but the pace of change in Haskell is far different 
> than the pace in web development, applications, or OSes--- so I'm wary 
> of how much experience from those areas can be effectively ported to 
> this task.

Right, the experience of other communities is our best guide but there
are things unique to each group.

For example it's fine for an application to come out every couple
months. There's no particular problem in the user base using a wide
range of versions. However with a programming platform we get network
effect benefits when we're mostly using the same versions of most common
packages most of the time. (API additions cut network connections in one
direction while API breaks cut network connections in both.)

> Another important issue that hasn't been much discussed is how long and 
> to what extent do you plan to maintain old releases? I think the answer 
> to this question will have major repercussions on both the frequency of 
> non-bugfix releases and on whether it would be meaningful to distinguish 
> enhancements from changes.

My guess is that it'd be feasible to aim to support three releases
simultaneously. At a 6 month cycle that'd be 18 months.

> > You bring up some good points about the pressure for maintainers to get
> > new features into major releases. This is an important consideration in
> > major release frequency. I suggest you take a look at Martin Michlmayr's
> > PhD thesis in which he discusses this issue.
> > 
> >         Quality Improvement in Volunteer Free and Open Source Software
> >         Projects: Exploring the Impact of Release Management
> >         http://www.cyrius.com/publications/michlmayr-phd.html
> 
> I have, it's a good read :)  In Michlmayr's terms, I'm advocating for 
> the notion of development releases for the HP as separate from 
> development releases for the underlying projects on Hackage.

Right, the HP would always be picking up existing releases from Hackage.

> Cutting edge vs bleeding edge, as it were. This is similar to GCC's
> three-tier model. Also it should make it easier to avoid
> OpenOffice.org's QA problems, while maintaining frequent (3~4 month)
> non-bugfix releases.

So it looks like the only thing we don't quite agree on is the frequency
of the release cycle, though at least we do have overlapping ranges :-)
(3~4 vs 4~6)

Duncan