[Haskell-cafe] Checking in packages to Hackage early in
development cycle?
Duncan Coutts
duncan.coutts at worc.ox.ac.uk
Fri Mar 20 06:30:21 EDT 2009
On Thu, 2009-03-19 at 12:56 -0400, Brandon S. Allbery KF8NH wrote:
> On 2009 Mar 19, at 12:39, Brandon S. Allbery KF8NH wrote:
> > On 2009 Mar 19, at 12:30, Colin Paul Adams wrote:
> >>>>>>> "Max" == Max Rabkin <max.rabkin at gmail.com> writes:
> >>
> >> Max> On Thu, Mar 19, 2009 at 4:41 PM, Manlio Perillo
> >> Max> <manlio_perillo at libero.it> wrote:
> >>
> >> Max> Personally, I think that there is little harm in releasing a
> >> Max> package if it does something useful in a not-totally-broken
> >> Max> way. Especially if you plan to extend it.
> >>
> >> Suppose you intend to extend it, and are not sure yet if the
> >> interface
> >> will change as a result?
> >
> > Generally you indicate this by changing the minor version: 0.3.0,
> > 0.3.1, etc. have compatible APIs, but 0.4.0 has an incompatible
> > API. And with major version 0, API breakage is expected in new
> > releases.
We call it the Package versioning policy (PVP)
http://www.haskell.org/haskellwiki/Package_versioning_policy
Package authors are encouraged but not required to follow it. In the not
too distant future you will be able to explicitly opt-in, in which case
we will try to check that the package does indeed follow the policy and
advising authors of dependent packages about the kind of version
constraints they should use.
> Oh, and to address your question more directly: it's by getting your
> package out there where people will find it (i.e. on hackage, since
> that's where people look) that you get more eyes on it and hopefully
> more ideas as to how to evolve it.
Yes, early feedback from users is invaluable in API design.
Duncan
More information about the Haskell-Cafe
mailing list