Platform policy question: API compatability in minor releases
wren ng thornton
wren at community.haskell.org
Sat May 9 23:22:02 EDT 2009
> > 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.
More information about the Libraries