Platform policy question: API compatability in minor releases

[Duncan Coutts]

On Wed, 2009-05-13 at 19:16 +0200, Sven Panne wrote:
> Am Montag, 11. Mai 2009 10:40:27 schrieb Duncan Coutts:
> > On Sun, 2009-05-10 at 12:05 +0200, Sven Panne wrote:
> > > [...]
> > >    * Consistency in numbering: The platform numbering should have the
> > > semantics as the numbering of its parts, therefore allowing API additions
> > > in minor releases. If someone is totally unwilling to risk any changes
> > > his code, he can still use bug fix releases of the platform instead of
> > > minor releases, where's the problem?
> >
> > We can make the numbering consistent with whichever policy we choose.
> > [...]
> 
> I don't think so: http://www.haskell.org/haskellwiki/Package_versioning_policy 
> clearly states our numbering policy for libraries, and if you regard the API 
> of the HP as the union of the API of its constituent libraries, there is no 
> choice at all if the HP wants to conform to the PvP. And I can't see a reason 
> why the HP should be considered a special case here.

If we choose to allow compatible API changes in minor release then we'd
use version numbers like:

  X.Y.0 for the first release / major release
  X.Y.1 for the next minor release

If we choose to allow only bug-fix changes changes in minor releases (ie
no API changes) then we'd use version numbers like:

  X.Y.0.0 for the first release / major release
  X.Y.0.1 for the next minor release

In both cases this compiles with the PVP and in both cases the union is
consistent with it components.

Am I missing something?

Yes, the second option is a change from the version number scheme what
we've been proposing. We didn't initially think about the PVP when
designing it. It is clear that everyone else thinks it is important and
we have no objection to changing the scheme so that it does follow the
PVP, indeed it's a sensible and consistent thing to do.

The only thing causing confusion has been whether we interpret the
existing platform versioning proposal in the light of the PVP and then
change the platform API policy to suit, or if we decide our policy and
then adjust the platform versioning scheme to follow the PVP. The latter
approach is clearly more sensible.

Duncan