Re: [Haskell] ANNOUNCE: Sifflet visual programming language, release 0.1.7

newer
Re: [Gtk2hs-users] Woes on MacOS...

older
Similarities between web...

Henning Thielemann

11 Jun 2010 11 Jun '10

2:51 p.m.

On Fri, 11 Jun 2010, Ben Millwood wrote:

...

On Fri, Jun 11, 2010 at 2:52 PM, Henning Thielemann wrote:

...
I'm uncertain whether fgl conforms to the package versioning policy, but if it does, then changes in its Cabal file should not bother sifflet. Thus upper bound fgl < 5.4.3 should be restrictive enough.

The PVP says that one of the first two numbers are required to change if an API change is likely to break code using it, so < 5.5 would probably suffice.

A bump to fgl-5.4.3 might include API *extensions* that may break sifflet, if it imports entire FGL modules in an unqualified way.

Show replies by date

gdweber＠iue.edu

12 Jun 12 Jun

7:43 p.m.

New subject: [Haskell] ANNOUNCE: Sifflet visual programming language, release 0.1.7

Thanks to all for reminding me of the Package Versioning Policy (PVP); I have refreshed my memory of it here: http://www.haskell.org/haskellwiki/Package_versioning_policy The message I'm picking up from this thread is that In *theory* if my package works with some other package P, version A.B.C, and a. I'm importing the whole module P unqualified, then my cabal file should say my package depends on P >= something && < A.B.(C+1). b. If I'm importing P qualified or only certain names from P, then I can be more relaxed in my cabal file can say my package depends on P >= something && < A.(B+1). In reality, eternal vigilance is required, since some packages may be released with new version numbers not conforming to the PVP. But what about *lower* bounds for package dependencies? I think what I tend to do is something like this. I'm developing my package and using P with installed version P == A.B.C. So I write in my cabal file that it depends on P >= A.B.C. Then some time later, I get a newer version of P with version A'.B'.C' > A.B.C, and I'm not aware of any significant changes, so I go on declaring in my cabal file that my package depends on P >= A.B.C, even though I *might* be using new features of P that wouldn't work with P == A.B.C. Does anyone suggest a better way of dealing with the lower bound package versioning? Greg

...

On Fri, 11 Jun 2010, Ben Millwood wrote:

...
On Fri, Jun 11, 2010 at 2:52 PM, Henning Thielemann wrote:

...
I'm uncertain whether fgl conforms to the package versioning policy, but if it does, then changes in its Cabal file should not bother sifflet. Thus upper bound fgl < 5.4.3 should be restrictive enough.

The PVP says that one of the first two numbers are required to change if an API change is likely to break code using it, so < 5.5 would probably suffice.

A bump to fgl-5.4.3 might include API *extensions* that may break sifflet, if it imports entire FGL modules in an unqualified way. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- ___ ___ __ _ / _ \ / _ \| | | | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \____/\_____/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550

Daniel Fischer

8:05 p.m.

New subject: [Haskell] ANNOUNCE: Sifflet visual programming language, release 0.1.7

On Saturday 12 June 2010 21:43:25, gdweber@iue.edu wrote:

...

Thanks to all for reminding me of the Package Versioning Policy (PVP); I have refreshed my memory of it here:

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

The message I'm picking up from this thread is that

In *theory* if my package works with some other package P, version A.B.C, and a. I'm importing the whole module P unqualified, then my cabal file should say my package depends on P >= something && < A.B.(C+1). b. If I'm importing P qualified or only certain names from P, then I can be more relaxed in my cabal file can say my package depends on P >= something && < A.(B+1).

In reality, eternal vigilance is required, since some packages may be released with new version numbers not conforming to the PVP.

But what about *lower* bounds for package dependencies? I think what I tend to do is something like this. I'm developing my package and using P with installed version P == A.B.C. So I write in my cabal file that it depends on P >= A.B.C.

And P < A.(B+1) Always include upper bounds on your dependencies. Even if it will actually work with all versions of P up to (A+5), you don't know that, and if it breaks with A.(B+1), the hassle will probably be worse than the hassle an unnecessarily restrictive upper bound gives.

...

Then some time later, I get a newer version of P with version A'.B'.C' > A.B.C, and I'm not aware of any significant changes,

Test your package with the new version, and if it works, raise the upper bound in your .cabal file.

...

so I go on declaring in my cabal file that my package depends on P >= A.B.C, even though I *might* be using new features of P that wouldn't work with P == A.B.C.

If you're changing the code to use new features of P, you have to raise the lower bound of the dependency. If you don't use any new features, it would continue working with P-A.B.C, so you can leave the lower bound.

...

Does anyone suggest a better way of dealing with the lower bound package versioning?

Give the smallest version you know your package to work with.

...

Greg

Ben Millwood

10:40 p.m.

New subject: [Haskell] ANNOUNCE: Sifflet visual programming language, release 0.1.7

On Sat, Jun 12, 2010 at 9:05 PM, Daniel Fischer wrote:

...

On Saturday 12 June 2010 21:43:25, gdweber@iue.edu wrote:

...
so I go on declaring in my cabal file that my package depends on P >= A.B.C, even though I *might* be using new features of P that wouldn't work with P == A.B.C.

If you're changing the code to use new features of P, you have to raise the lower bound of the dependency. If you don't use any new features, it would continue working with P-A.B.C, so you can leave the lower bound.

It's not always easy to remember or tell when you break compatibility with old versions. I came up with this idea for cabal-install to aid in development: http://hackage.haskell.org/trac/hackage/ticket/661 which I think would help, but it's not been written yet. Maybe add yourself to the CC list if you're eager to see it happen.

5506

Age (days ago)

5507

Last active (days ago)

List overview

Download

3 comments

4 participants

participants (4)

Ben Millwood
Daniel Fischer
gdweber＠iue.edu
Henning Thielemann