Re: [Haskell-cafe] Package Versioning Policy

newer
Sudden monomorphism with...

older
Get a variable's type in quasiquote

Christoph Breitkopf

5 Jan 2012 5 Jan '12

12:05 p.m.

Forgot the header, sorry. On Thu, Jan 5, 2012 at 5:54 PM, Christoph Breitkopf < chbreitkopf@googlemail.com> wrote:

...

Hello,

I'm trying to figure out how to handle versioning of my IntervalMap package. I've just read the package versioning policy: http://www.haskell.org/haskellwiki/Package_versioning_policy

I don't quite understand all the recommendations in the above document, though:

a) You are not allowed to remove or change the types of existing stuff. Ok.

b) You are allowed to add new functions. But that can break compilation because of name conflicts. Seems to be allowed on the grounds that this is easy to fix in the client code.

c) You are not allowed to add new instances. I don't get this - how is this any worse than b)?

I do understand that it is not generally possible to prevent breaking code - for example if the client code depends on buggy behavior that gets fixed in a minor version update. That seems unavoidable - after all, bugfixes are _the_ reason for minor updates.

Regards,

Chris

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Attachments:

attachment.html (text/html — 1.8 KB)

Show replies by date

Johan Tibell

5 Jan 5 Jan

12:15 p.m.

New subject: Package Versioning Policy

On Thu, Jan 5, 2012 at 9:05 AM, Christoph Breitkopf wrote:

...

...
a) You are not allowed to remove or change the types of existing stuff. Ok.

Unless you bump the major version number (i.e. X or Y in X.Y.Z.P). That way people can depend on IntervalMap == X.Y.Z.* and be guaranteed that their package won't fail to compile if you release a bugfix to X.Y (which would increase the patch component of the version number).

...

...
b) You are allowed to add new functions. But that can break compilation because of name conflicts. Seems to be allowed on the grounds that this is easy to fix in the client code.

I cannot break compilation if you use explicit import lists or qualified imports. People who use that (which I recommend they do) can specify a dependency on IntervalMap == X.Y.* and still be guaranteed not to break if you make a new (minor) release.

...

...
c) You are not allowed to add new instances. I don't get this - how is this any worse than b)?

You cannot prevent the import of new instances. When you import a module you get all its instances. This means that explicit import lists can't protect you.

...

...
I do understand that it is not generally possible to prevent breaking code - for example if the client code depends on buggy behavior that gets fixed in a minor version update. That seems unavoidable - after all, bugfixes are _the_ reason for minor updates.

Bugfixes you be in bugfix releases (i.e. bumps to the 4th version component.) Yes, if you depend on bugs you might have your code break. There's no way around this. In practice it hasn't been a problem. -- Johan

Christoph Breitkopf

12:30 p.m.

New subject: Package Versioning Policy

HI, On Thu, Jan 5, 2012 at 6:15 PM, Johan Tibell wrote:

...

...
...
c) You are not allowed to add new instances. I don't get this - how is this any worse than b)?

You cannot prevent the import of new instances. When you import a module you get all its instances. This means that explicit import lists can't protect you.

What I don't get is how a new instance may break existing code. Any example? Bugfixes you be in bugfix releases (i.e. bumps to the 4th version

...

component.)

I though I would do without the patchlevel component at first. If I understand correctly, you would recommend: - Mayor Version changes: as described in the guidelines: changed interface, new instances - Minor version change: when I just add functions - Patchlevel change: for bugfixes, performance fixes, documentation changes Thanks, Chris

Brandon Allbery

1:14 p.m.

New subject: Package Versioning Policy

On Thu, Jan 5, 2012 at 12:30, Christoph Breitkopf < chbreitkopf@googlemail.com> wrote:

...

On Thu, Jan 5, 2012 at 6:15 PM, Johan Tibell wrote:

...
...
...
c) You are not allowed to add new instances. I don't get this - how is this any worse than b)?

You cannot prevent the import of new instances. When you import a module you get all its instances. This means that explicit import lists can't protect you.

What I don't get is how a new instance may break existing code. Any example?

It's not unusual for people to define their own instances for things; if a new release of the library then adds its own version of those instances, even if they are identical, then those people's code will break. Google "orphan instances" to see both general and concrete discussion of the problem. I'm blanking on recent practical examples, but there have been some. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

Christoph Breitkopf

5 p.m.

New subject: Package Versioning Policy

...

...
What I don't get is how a new instance may break existing code. Any example?

It's not unusual for people to define their own instances for things; if a new release of the library then adds its own version of those instances, even if they are identical, then those people's code will break. Google "orphan instances" to see both general and concrete discussion of the

Am 05.01.2012 19:14 schrieb "Brandon Allbery" : problem.

...

I'm blanking on recent practical examples, but there have been some.

I see. No examples needed - I just had to do that myself in benchmark code, because FingerTree does not instance NFData. When it does, my code will break. Got that. Thanks, Chris

Johan Tibell

2:08 p.m.

New subject: Package Versioning Policy

On Thu, Jan 5, 2012 at 9:30 AM, Christoph Breitkopf wrote:

...

If I understand correctly, you would recommend:

- Mayor Version changes: as described in the guidelines: changed interface, new instances - Minor version change: when I just add functions - Patchlevel change: for bugfixes, performance fixes, documentation changes

Yes. This is in fact what the PVP specifies IIRC. -- Johan

Christoph Breitkopf

4:54 p.m.

New subject: Package Versioning Policy

Am 05.01.2012 20:08 schrieb "Johan Tibell" :

...

...
- Mayor Version changes: as described in the guidelines: changed

interface,

...

...
new instances - Minor version change: when I just add functions - Patchlevel change: for bugfixes, performance fixes, documentation changes

Yes. This is in fact what the PVP specifies IIRC.

It says that anything beyond the minor version is optional. Also, in the cabal files I looked at, most seemed to use the major version for dependencies, e.g. package >= 0.5 < 0.6. So I wondered if I misunderstood, or if the maintainers of those packages just live with the risk of minor breakage once in a while. But anyway, I'm not trying to be overly pedantic - I'm just new to the Haskell community, so I ask a lot of questions ;-) Thanks again, Chris

4888

Age (days ago)

4888

Last active (days ago)

List overview

Download

6 comments

3 participants

participants (3)

Brandon Allbery
Christoph Breitkopf
Johan Tibell