Package versioning policy

[Michael Snoyman]

Hey,

Any chance on getting Hack to follow the Haskell PVP? (http://www.haskell.org/haskellwiki/Package_versioning_policy)

It would make it easier to specify valid version ranges.

Thanks,
Michael

[Jinjing Wang]

mypkg >= 2.1.1 && < 2.1.2

hack >= 2008.12.1 && < 2009.12.1

I never tried, but it should work, no?

> --
>
> You received this message because you are subscribed to the Google Groups
> "hack-discuss" group.
> To post to this group, send email to hack-d...@googlegroups.com.
> To unsubscribe from this group, send email to
> hack-discuss...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hack-discuss?hl=en.
>



--
jinjing

[Michael Snoyman]

It works just fine, what this is addressing is that the version numbers in Hack should *mean* something. Currently, AFAIK, they are just dates, which say nothing about API compatibility.

Michael

[Jinjing Wang]

It has not cause a problem, and I can't think of an instance where it
would where the haskell's version policy would not, so unless the
proposed policy offers a real technical benefice, I see no reason to
change it.

Besides, I like dates, it means something, where 2.3.0.0 is just an
arbitrary number.

[Michael Snoyman]

Here's the issue:

I write a web app to depend on:

hack >= 2008.12.1 && < 2009.12.1 (as you specify above)
hack-handler-cgi >= 0.0.2 && < 0.1

Then, you release hack-2010.1.1. It introduces no breaking changes, just updates some documentation.

I make some changes to hack-handler-cgi to update specs to match current documentation. I change it to version 0.0.3 and update the hack requirement to:
hack >= 2010.1.1 && < 2010.2

Now my web app won't build without changing the requirements. If I leave off the upper bound on the hack version, then if you *do* make a breaking change, my web app will also die.

Basically: the way you do it now, assuming a maximum of one release per month, means that every time you update a version number every user must manually check if there is a breaking change. That's what Haskell version numbers are meant to specify

I haven't even gotten into if you release hack 2010.1.1 and 2010.1.2 with breaking changes, which is much worse.

Michael

[Jinjing Wang]

Thanks for explaining!

But I think your app will still build, that's one of the feature of
cabal, to figure out dependencies recursively based on constraints
specified in each dependent packages, so I think your app will depends
on the earlier version of hack before 2010.1.1 and earlier version of
hack-handler-cgi before 0.0.3.

[Michael Snoyman]

And why would I want to be building with the old version of hack-handler-cgi? And what if another component in my project specifically required the newer version of hack-handler-cgi? These are issues that come up very often in Haskell. There's a reason the PVP was created, I don't think we should just ignore it.

Michael

[Jinjing Wang]

If there were no breaking change, there's no reason to enforce on new
version of hack in hack-handler-cgi right?

[Michael Snoyman]

Then let's address the other direction: you introduce a breaking change between 2010.1.1 and 2010.1.2. My application specifies hack >= 2010.1.1 && < 2010.2, as per the PVP. Suddenly, it breaks.

I know you might tell me "then just depend on 2010.1.1 explicitly," but that's just going completely against Haskell versioning policy. Why would you want to make Hack an exception to a rule which is supposed to apply to every package on hackage?

Michael

[Jinjing Wang]

Indeed, it will require bumping version in cabal to use the new feature.

However consider the haskell's policy's case.

It's a breaking change, so hack will bump a major version upgrade, say
2.2.0.0 to 2.3.0.0, your app is likely to depends on >= 2.2.0.0 <
2.3.0.0, for api stability. It still needs to bump version to take
advantage of the new change.

The version policy sounds good, but in practice does not offer
anything I can see, other then enforcing people to do things in its
way.

I'm not against it, I just don't want to blindly follow it.

[Michael Snoyman]

I think I didn't clarify my point well enough there. The case I'm worried about is where I expect you to follow the PVP, and you break the PVP by introducing a breaking change between versions 2010.1.1 and 2010.1.2. My app will say:

hack >= 2010.1.1 && < 2010.2

It will build happily until you release 2010.1.2, when suddenly it will no longer function. I'm trying to avoid that situation. I should have started off this discussion with this case, since it is more important than the other side of the coin.

Michael

[Jinjing Wang]

why will it not function? cabal will only let your app build against
an earlier version of hack before 2010.2, since you specified it
should build against hack < 2010.2.

[Michael Snoyman]

Correct... and you just bumped to version 2010.1.2, which *is* less than 2010.2.

Michael

[Jinjing Wang]

Oh, I didn't see it clearly.

You should specify the exact upper bound, then there won't be a problem.

[Michael Snoyman]

And that's what the PVP addresses. You give no way for me to know which versions of Hack are breaking versions. Even if you documented it somewhere, that would require looking it up somewhere, as opposed to following the PVP which would simply mean I could treat it like any well-behaving Haskell package.

The only solution I see to the current situation is picking a specific version of Hack and not changing from it, which I don't think is a good one.

Michael

[Jinjing Wang]

You can always specify the exact upper bound and be safe.

I always just leave out the upper bound in all libraries I use and
expect to fix it when they change, if I don't want to maintain a
project anymore, I'll leave it to a fixed upper bound.

The biggest problem of cabal right now is split packages, that is a
few widely used packages depend on different major versions of the
same package, hence dividing the library network.

Suggesting developers to use PVP is not going to fix this way more
serious issue, imho. With rolling releases, more packages will break,
but it might lead to better overall quality of the network.

I don't know if PVP is a good thing yet, so I don't want to adopt it.

[Michael Snoyman]

Then I'll probably be pegging all my projects at 2009.10.30. Until the situation changes, I doubt I'll be updating any of my packages.

Michael

[Michael Snoyman]

On Sun, Dec 6, 2009 at 7:24 AM, Jinjing Wang <nfji...@gmail.com> wrote:

You can always specify the exact upper bound and be safe.

I always just leave out the upper bound in all libraries I use and
expect to fix it when they change, if I don't want to maintain a
project anymore, I'll leave it to a fixed upper bound.

The biggest problem of cabal right now is split packages, that is a
few widely used packages depend on different major versions of the
same package, hence dividing the library network.

Suggesting developers to use PVP is not going to fix this way more
serious issue, imho. With rolling releases, more packages will break,
but it might lead to better overall quality of the network.

I don't know if PVP is a good thing yet, so I don't want to adopt it.

Sorry to beat the dead horse, but I just want to confirm I understand where we stand on this issue:

* The PVP specifies a practice of version number whereby you can automatically know based on version number whether a package introduces a potentially breaking change.
* You feel that it's OK for old versions of packages to break because a new version of a different package is released. This issue is irrelevant because the "divided hackage" issue is more important.
* Since you don't care about your old packages breaking, you have no intention of letting users of Hack know when a potentially breaking change will occur based on the fairly well-accepted PVP. Therefore, users of Hack have two options:
  * Accept the fact that our old packages can break because you release a breaking change.
  * Peg our packages at a specific version number of Hack, thereby splitting Hackage even when there was only a non-breaking change.

I believe if you analyze the decision, you'll realize that it's possible for you to release packages the way you want and still follow the PVP for Hack without any conflict. Also, not following the PVP is *more* likely to introduce splits in Hackage than following it.

Let me know if I'm mistaken.

Michael

[Jinjing Wang]

That's pretty much true. I'm not afraid to break others' libraries,
and I don't promise API stability neither. Library author always have
the option to fix on a specific version, as explained earlier.

If I may say, this is not just the way I treat Hack, I release all my
libraries with date based versioning.

In fact, I disagree with many opinions from the community ( of course,
also strongly agree with many ) , like not making haskell platform a
rolling release along with the latest compiler beta is an obvious
mistake, from my point of view.

All I'm trying to say is that, if this version policy is really a big
issue for you, why not fork the hack architecture? In it's core
there's just one file. Those who share the same view will benefit, and
it's a great way to show the real benefit of PVP, when people follow
along.

[Michael Snoyman]

On Tue, Dec 8, 2009 at 2:19 PM, Jinjing Wang <nfji...@gmail.com> wrote:

That's pretty much true. I'm not afraid to break others' libraries,
and I don't promise API stability neither. Library author always have
the option to fix on a specific version, as explained earlier.

If I may say, this is not just the way I treat Hack, I release all my
libraries with date based versioning.

In fact, I disagree with many opinions from the community ( of course,
also strongly agree with many ) , like not making haskell platform a
rolling release along with the latest compiler beta is an obvious
mistake, from my point of view.

All I'm trying to say is that, if this version policy is really a big
issue for you, why not fork the hack architecture? In it's core
there's just one file. Those who share the same view will benefit, and
it's a great way to show the real benefit of PVP, when people follow
along.

The only reason I got into Hack in the first place is that I wanted to try to standardize things. If I thought just creating another package on Hackage would accomplish my goals, I would have done that instead of having all the previous arguments I've had about how things should progress here.

That said, I hope you reconsider your opinion that breaking other people's libraries is perfectly acceptable. You may not care about stability, but the rest of the community seems to be going in the direction of resilient products, not brittle ones.

Michael

[Jinjing Wang]

I really appreciated it. I hope hack can still serve you well, and I
hope the benefit of using it may out weight the dissatisfaction.