Bumping package version numbers in the HP (Was: Haskell Platform Proposal: add transformers and revise the mtl package to depend on it)
Hi all,
On Tue, Nov 2, 2010 at 2:47 PM, Ross Paterson
The ones that depend on mtl are:
cgi-3001.1.7.3 (latest version 3001.1.8.1) fgl-5.4.2.3 QuickCheck-2.1.1.1 (latest version 2.3.0.2) regex-base-0.93.2 regex-compat-0.93.1 regex-posix-0.94.2 HTTP-4000.0.9 (latest version 4000.0.10)
How do we decide whether to include new versions of packages in the next HP release. For bugfix releases it should be a no-brainer, just include them. What about API additions? Didn't we chose to not use a new version of some package because it added a bunch of modules in the Data.* namespace? As you see above two packages have increased the minor version number (cgi and HTTP) and one has increased the major version number (QuickCheck). In addition to the above three packages, the network package recently grew two new modules (adopted from network-bytestring). Johan
On Tue, Nov 02, 2010 at 03:00:23PM +0100, Johan Tibell wrote:
How do we decide whether to include new versions of packages in the next HP release. For bugfix releases it should be a no-brainer, just include them. What about API additions?
I think the idea is that anything not obviously OK goes through the community consensus process. Some API additions could be obviously OK, though.
In addition to the above three packages, the network package recently grew two new modules (adopted from network-bytestring).
But that's already been through the process, so is fine. Thanks Ian
On 2 November 2010 14:00, Johan Tibell
How do we decide whether to include new versions of packages in the next HP release. For bugfix releases it should be a no-brainer, just include them. What about API additions?
There is a distinction between HP minor and major releases. API changes in major releases are fine, for minor releases we stick to bug fixes only.
Didn't we chose to not use a new version of some package because it added a bunch of modules in the Data.* namespace?
That was because it simultaniously split into multiple packages and those new packages did not keep the old namespace but used modules in Data.*. We decided that this meant they were new dependencies and new deps have to go through the proposal process.
As you see above two packages have increased the minor version number (cgi and HTTP) and one has increased the major version number (QuickCheck).
In addition to the above three packages, the network package recently grew two new modules (adopted from network-bytestring).
This is all fine. There is no problem with API updates. Where things become more questionable is where there is a major discontinuity, e.g. a complete reimplementation by a new maintainer without a clear handover between maintainers. Duncan
participants (3)
-
Duncan Coutts -
Ian Lynagh -
Johan Tibell