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,
http://haskell.org/haskellwiki/Package_versioning_policy#Version_numbers
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.
+1. -- Live well, ~wren