Re: [Haskell-cafe] Package Versioning Policy
Forgot the header, sorry. On Thu, Jan 5, 2012 at 5:54 PM, Christoph Breitkopf chbreitk...@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package Versioning Policy
On Thu, Jan 5, 2012 at 9:05 AM, Christoph Breitkopf chbreitk...@googlemail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package Versioning Policy
HI, On Thu, Jan 5, 2012 at 6:15 PM, Johan Tibell johan.tib...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package Versioning Policy
On Thu, Jan 5, 2012 at 12:30, Christoph Breitkopf chbreitk...@googlemail.com wrote: On Thu, Jan 5, 2012 at 6:15 PM, Johan Tibell johan.tib...@gmail.comwrote: 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 allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package Versioning Policy
On Thu, Jan 5, 2012 at 9:30 AM, Christoph Breitkopf chbreitk...@googlemail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package Versioning Policy
Am 05.01.2012 20:08 schrieb Johan Tibell johan.tib...@gmail.com: - 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package Versioning Policy
Am 05.01.2012 19:14 schrieb Brandon Allbery allber...@gmail.com: 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. 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package versioning policy - Harmless type changes?
Joachim Breitner wrote: Felipe Almeida Lessa wrote: Given that you are following the PVP, I would put the following constraint: Build-depends: foo = 0.1 0.2 However, if someone with an older version of foo installed on their system tried to install my package, they would get a type error, since I haven't put a Typeable a = context on my bar. would you? I think you would use foo = 0.1.3 0.2, because 0.1.3 is allowed to have API additions that are not in 0.1.2, so if you develop your library against 0.1.3, there is no guarantee that foo was not empty in 0.1.2. Under this interpretation, removing a constraint should be equivalent to an API addition, hence rule 2 on http://www.haskell.org/haskellwiki/Package_versioning_policy#Version_numbers ought to apply. I like that point of view. In a sense, generalizing a type is literally equivalent to adding a new function to the API which can be used in new contexts. The only difference is that the new function has the same name as the old one. It's not entirely safe to generalize a type, though, due to issues with type classes and ambiguity. For instance, the generalization read :: Read a = String - a - showDouble :: Double - String + showDouble :: Floating a = a - String will break the program foo :: String - String foo = showDouble . read That said, is it true that *removing* a class constraint will never cause ambiguities? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Package versioning policy - Harmless type changes?
Dear all, the package versioning policy specifies that changing the type of any entity makes a change of the B number in A.B.C necessary. However, it seems to me that a small selection of type changes don't break dependent code. In particular, consider the following example, where I drop a Typeable class constraint: - foo :: Typeable a = AddHandler a - NetworkDescription (Event a) + foo :: AddHandler a - NetworkDescription (Event a) Can removing a type class constraint on a function break dependent code? Should I change the B number or just the C in version A.B.C when introducing this change? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package versioning policy - Harmless type changes?
On Thu, Sep 22, 2011 at 7:37 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: - foo :: Typeable a = AddHandler a - NetworkDescription (Event a) + foo :: AddHandler a - NetworkDescription (Event a) Can removing a type class constraint on a function break dependent code? Should I change the B number or just the C in version A.B.C when introducing this change? This change would break only backwards compatibility. For example, suppose that the version with Typeable a = is 0.1.2 and the version without is 0.1.3. Suppose that you have already released your version 0.1.3 when I create a package with the value: bar :: NetworkDescription (Event (Set a)) bar = ... foo ... Given that you are following the PVP, I would put the following constraint: Build-depends: foo = 0.1 0.2 However, if someone with an older version of foo installed on their system tried to install my package, they would get a type error, since I haven't put a Typeable a = context on my bar. So, yes, that change can break some code. Is that change big enough to be considered harmful? I don't know =), probably not. Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package versioning policy - Harmless type changes?
Hi, Am Donnerstag, den 22.09.2011, 08:32 -0300 schrieb Felipe Almeida Lessa: On Thu, Sep 22, 2011 at 7:37 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Given that you are following the PVP, I would put the following constraint: Build-depends: foo = 0.1 0.2 However, if someone with an older version of foo installed on their system tried to install my package, they would get a type error, since I haven't put a Typeable a = context on my bar. would you? I think you would use foo = 0.1.3 0.2, because 0.1.3 is allowed to have API additions that are not in 0.1.2, so if you develop your library against 0.1.3, there is no guarantee that foo was not empty in 0.1.2. Under this interpretation, removing a constraint should be equivalent to an API addition, hence rule 2 on http://www.haskell.org/haskellwiki/Package_versioning_policy#Version_numbers ought to apply. Greetings, Joachim -- Joachim nomeata Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
