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