Re: [Haskell-cafe] Checking in packages to Hackage early in development cycle?

2009/3/20 Colin Paul Adams :

...

...

...

...

...

"Duncan" == Duncan Coutts writes:

Duncan> 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 writes:

Max> On Thu, Mar 19, 2009 at 4:41 PM, Manlio Perillo Max> 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.

Duncan> We call it the Package versioning policy (PVP)

Duncan> http://www.haskell.org/haskellwiki/Package_versioning_policy

Duncan> Package authors are encouraged but not required to follow Duncan> it. In the not too distant future you will be able to Duncan> explicitly opt-in, in which case we will try to check that Duncan> the package does indeed follow the policy and advising Duncan> authors of dependent packages about the kind of version Duncan> constraints they should use.

I missed the upper bounds on dependencies. How am I supposed to know what the upper bound is?

I don't know what is the consensus, but I always thought that dependencies should simply state what versions work. So the upper bound would be the current version. If a new version appears, just bump the version too, even if nothing changed in the code. Makes sense ? Thu