Platform policy question: API compatability in minor releases

wren ng thornton wren at
Sat May 9 23:22:02 EDT 2009

> duncan.coutts:
> > The question is this:
> >
> >         Should we allow compatible API additions to a library in a minor
> >         release of the platform?
> >         
> >         The choice is between allowing only bug fixes in minor releases,
> >         or also allowing new features that add APIs but do not change
> >         any existing APIs.

Do we need to fixate on one or the other? That is, I think it'd be nice 
to allow both, distinguishing them by the magnitude of the version 
change (e.g. the 3rd vs the 4th magnitude, ala the PVP).

It can be a burden for developers to maintain separate forks of their 
projects to distinguish bug fixes from API upgrades, but it seems like 
it would be easy for THP to maintain separate lines--- to the extent it 
can automate everything.

My proposal is, every time a "minor update" is to be made, THP could 
fork x.y.z.a and provide x.y.z.(a+1) which only includes bug-fix 
improvements and also x.y.(z+1).(a+1) which includes both bug-fix and 
compatible-API updates. Every time there's a "major update", all these 
branches would merge back together and be obviated by the new major 
version. Naturally this scheme is predicated on being able to automate 
most of the work for updating THP.

Don Stewart wrote:
> I'd like to ensure that the Haskell Platform respects the minor
> versioning policy for its constituent parts, specified,
> That is, if a library author follows the minor version number bump
> policy, then they can reasonably expect to have that library bump
> included in the next minor bump of the platform.
> If we agree on this, a lot of the decision making for library bumps
> becomes automated. If we don't, we have to distinguish case-by-case
> whether a library bump added to the API.
> Summary: the Platform policy should follow the policy of its consituent parts.


Live well,

More information about the Libraries mailing list