Re: [Haskell] Re: Please check your dependencies on fgl
Hey Robby, Yeah, two documents: The "PVP" http://www.haskell.org/haskellwiki/Package_versioning_policy The Package Addition Policy for the Haskell Platform http://trac.haskell.org/haskell-platform/wiki/AddingPackages robby: > Hi all. Just thought I'd poke my head in here (perhaps where I'm not > wanted...) to ask: is there a rationale and/or guidelines for how to > use version numbers in hackage somewhere that I could read? > > I ask because we worry that similar things to this discussion would > come up in PLaneT, the Racket package management scheme (if you're > curious see http://planet.racket-lang.org/ for the site or > http://docs.racket-lang.org/planet/index.html for the documentation). > > We preemptively resolved this kind of thing by tweaking the semantics > of version numbers. Specifically, if you ask for version 1.3, say, of > a package, PLaneT will give you the largest version that has the same > major version number, ie the largest 1.x (that is compatible with the > version of Racket you're using, that is). The idea was that when > changes to the functionality happen, the package maintainer would bump > the major number and feel safe that old uses would not break. This > seems to have worked pretty well in practice, fwiw (PLaneT has been > around for six years so far). > > (We took inspiration for this particular issue by the way we've seen > major version numbers move into package names in various linux > distributions.) > > Robby ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Please check your dependencies on fgl
ivan.miljenovic: > Christian Maeder writes: > > > Ivan Lazar Miljenovic schrieb: > >>> Although parsec-3 can be used as an replacement for parsec-2 it would > >>> have been better, they had different names (as argued elsewhere for the > >>> haskell platform). > >> > >> I'm sorry, I don't recall this discussion: care to summarise? > > > > http://www.haskell.org/pipermail/libraries/2010-March/013101.html > > I've read through that thread, but I remain unconvinced. First of all, > I think there are a few misconceptions raised there (e.g. the gitit > discussion is because John Macfarlane doesn't want to use Parsec-3 for > Pandoc because it used to be slow and because it isn't available in > Debian; this latter point shouldn't be a concern for most software > IMHO; secondly, if the documentation of the 2.x series was better, then > why not improve the documentation of the 3.y series?). > > Maintaining Haskell98 compatability may be a valid concern (I don't know > how valid it is to most people, but I can see some people preferring > it). > > _Why_ should a library remain fixed at a particular version (unless of > course you are convinced it is perfect)? By creating a new package, > people will keep using the old version which will eventually bit-rot > rather than upgrading. > If it is a complete rewrite, with a new API, in what sense is it FGL? How is it true to Erwig's design? I think it is great you want to overhaul it, but I bet that FGL 6 (or whatever) is going to break a bunch of Hackage when you upload it -- because very very few fgl users specify a version range. Can you avoid that? -- Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Please check your dependencies on fgl
Christian Maeder writes: > Ivan Lazar Miljenovic schrieb: >>> Although parsec-3 can be used as an replacement for parsec-2 it would >>> have been better, they had different names (as argued elsewhere for the >>> haskell platform). >> >> I'm sorry, I don't recall this discussion: care to summarise? > > http://www.haskell.org/pipermail/libraries/2010-March/013101.html I've read through that thread, but I remain unconvinced. First of all, I think there are a few misconceptions raised there (e.g. the gitit discussion is because John Macfarlane doesn't want to use Parsec-3 for Pandoc because it used to be slow and because it isn't available in Debian; this latter point shouldn't be a concern for most software IMHO; secondly, if the documentation of the 2.x series was better, then why not improve the documentation of the 3.y series?). Maintaining Haskell98 compatability may be a valid concern (I don't know how valid it is to most people, but I can see some people preferring it). _Why_ should a library remain fixed at a particular version (unless of course you are convinced it is perfect)? By creating a new package, people will keep using the old version which will eventually bit-rot rather than upgrading. There are also a few other differences between the situations here: * A lot more packages use parsec than fgl, such that the conversion process is more difficult (whereas for those packages on Hackage that use fgl, over half have already responded that they'll fix the dependency problem such that the version update won't be a problem). * The most common reason given for not upgrading to parsec-3 was efficiency; we're going to work hard to make sure that the speeds are comparable if not better (since for the most part the data structure is the same, it's just the overall API that differs in terms of how function names, etc.). * Many people liked parsec-2; the common opinion on #haskell, etc. seems to be that fgl is full of warts and many people (such as Cale) prefer to use one-off custom graph implementations (e.g. IntMap IntSet) rather than use fgl. A lot of the changes we're making to fgl comes from taking into account what people don't like about the current layout of fgl. >> With fgl, the actual changes aren't that big on the user side of things >> if they want to keep using the defaults (it's not a drop-in replacement, >> but the _way_ to use it remains unchanged). > > I usually don't want to make even small changes at installation time. But this isn't an installation time change, it's a build/develop time change. >> The big difference is when people want to make custom instances; >> however, as far as I know no-one has created any custom instances for >> FGL's classes. > > Well, I've created a custom instance: > http://trac.informatik.uni-bremen.de:8080/hets/browser/trunk/Common/Lib/Graph.hs > and our hets project is not a hackageDB package. This looks very similar to what is currently called Data.Graph.Inductive.PatriciaTree; is there any particular reason for using your own custom variant? One thing you may like from the new fgl: proper Show, Read and Eq instances being available for graphs (since I know some people are annoyed that fgl currently doesn't have any method of serialising the graph for storage/transmission; so much so that someone has even resorted to converting the graph to/from Dot format and using that for serialisation). >> But by keeping the old fgl around as a separate package, there is then >> no real incentive to change/upgrade. If, however, we re-use the package >> name then it will be more obvious that there is a new and (hopefully) >> improved version available. > > Your "incentive" would be a "small annoyance" for me since it would > force me to change the dependency to "fgl < ..." until I find time to > test our code with the newer fgl version (without possible other > changes). It's a very simple change, however (and arguably you and everyone should always use bounded dependencies anyway just in case of this kind of problem). Arguably, changing the code may involve more time to take into account the new API. However, we aim to have sufficient advantages to the new version of fgl that people would _want_ to change. > (I still haven't updated from tabular-0.1.0.2 to tabular-0.2.x, yet.) Wow, considering that tabular-0.2.1.0 (the first in the 0.2.x series) came out over a year ago and you still haven't upgraded is a little surprising... As a compromise, we might consider not uploading the new version of fgl to hackage (or having the developmental version use a new name, similar to how darcs has darcs-beta for testing releases) and get that package deprecated and hidden once we're satisfied and make a formal release. However, I envisage having the new version fully developed and out by the end of the year (time permitting, etc.; I want to get the API right the first time so we don't have to go through this argument again next year
[Haskell] Re: Please check your dependencies on fgl
Ivan Lazar Miljenovic schrieb: >> Although parsec-3 can be used as an replacement for parsec-2 it would >> have been better, they had different names (as argued elsewhere for the >> haskell platform). > > I'm sorry, I don't recall this discussion: care to summarise? http://www.haskell.org/pipermail/libraries/2010-March/013101.html > With fgl, the actual changes aren't that big on the user side of things > if they want to keep using the defaults (it's not a drop-in replacement, > but the _way_ to use it remains unchanged). I usually don't want to make even small changes at installation time. > The big difference is when people want to make custom instances; > however, as far as I know no-one has created any custom instances for > FGL's classes. Well, I've created a custom instance: http://trac.informatik.uni-bremen.de:8080/hets/browser/trunk/Common/Lib/Graph.hs and our hets project is not a hackageDB package. > But by keeping the old fgl around as a separate package, there is then > no real incentive to change/upgrade. If, however, we re-use the package > name then it will be more obvious that there is a new and (hopefully) > improved version available. Your "incentive" would be a "small annoyance" for me since it would force me to change the dependency to "fgl < ..." until I find time to test our code with the newer fgl version (without possible other changes). (I still haven't updated from tabular-0.1.0.2 to tabular-0.2.x, yet.) Cheers Christian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Please check your dependencies on fgl
Ivan Lazar Miljenovic schrieb: [...] we don't need to repeat a parsec-2 vs parsec-3 discussion. There are obviously different opinions that cannot be easily changed. >> Well, I've created a custom instance: >> http://trac.informatik.uni-bremen.de:8080/hets/browser/trunk/Common/Lib/Graph.hs >> and our hets project is not a hackageDB package. > > This looks very similar to what is currently called > Data.Graph.Inductive.PatriciaTree; is there any particular reason for > using your own custom variant? I guess, Data.Graph.Inductive.PatriciaTree wasn't available when I created my own instance. Furthermore, I'm using more efficient functions directly on the graph that are not available via the graph class methods. > It's a very simple change, however (and arguably you and everyone should > always use bounded dependencies anyway just in case of this kind of > problem). Sure, I can live with either way. > Arguably, changing the code may involve more time to take into account > the new API. However, we aim to have sufficient advantages to the new > version of fgl that people would _want_ to change. I'll rather wait and see how the new FGL will look like and then consider if re-writing is worthwhile. >> (I still haven't updated from tabular-0.1.0.2 to tabular-0.2.x, yet.) > > Wow, considering that tabular-0.2.1.0 (the first in the 0.2.x series) > came out over a year ago and you still haven't upgraded is a little > surprising... Well, looking at our simple ascii usage, I decided to copy the used bits from the sources (one package less and its dependencies, to worry about). > As a compromise, we might consider not uploading the new version of fgl > to hackage (or having the developmental version use a new name, similar > to how darcs has darcs-beta for testing releases) and get that package > deprecated and hidden once we're satisfied and make a formal release. For me it's no big deal, if you make a new package fgl6 or make a new version fgl-6, because I'll stick to fgl-5.4.2.2 as long as I see fit. Others may complain, if their old sources no longer compile because they got fgl-6 instead of fgl-5 by whatever unintended circumstances. > However, I envisage having the new version fully developed and out by > the end of the year (time permitting, etc.; I want to get the API right > the first time so we don't have to go through this argument again next > year :p). I think, sources should go on hackageDB as soon as possible to get early feedback. Christian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Please check your dependencies on fgl
Christian Maeder writes: > Ivan Lazar Miljenovic schrieb: >> We considered giving it a new name (fgl', etc.) but figured that in the >> long term this wouldn't be advantagous. We feel that the situation is >> analogous to QuickCheck: when the new version came out most people kept >> using the old one until slowly the momentum shifted and more people >> started using the new version (without checking in depth, Roel's Hackage >> mirror reports QC-2.x now has 153 reverse dependencies as opposed to 127 >> reverse dependencies for QC-1.y). >> >> If we changed the name, then the "emotional attachment" that the Haskell >> community has to FGL being the de-facto graph library means that people >> would keep using the old version. Whilst we also face the possible >> problems of people not liking the old version and thus automatically >> dismissing the new version, I think this is a much more unlikely >> scenario. > > I'm afraid you'll destroy the "emotational attachment" to fgl by > annoying incompatibilities (and possibly interfering new bugs). > > Although parsec-3 can be used as an replacement for parsec-2 it would > have been better, they had different names (as argued elsewhere for the > haskell platform). I'm sorry, I don't recall this discussion: care to summarise? With fgl, the actual changes aren't that big on the user side of things if they want to keep using the defaults (it's not a drop-in replacement, but the _way_ to use it remains unchanged). The big difference is when people want to make custom instances; however, as far as I know no-one has created any custom instances for FGL's classes. > Changing a dependency in a cabal file is a small problem. > Those (unaware), who only mention "fgl", will fall over an > incompatibility (usually at installation time!) and simple say "fgl < > ..." unless they are willing to change their code then. > > Those who already have "fgl < ..." need to find an advertisement of a > "new and better fgl" anyway and can choose when to change their code. But by keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade. If, however, we re-use the package name then it will be more obvious that there is a new and (hopefully) improved version available. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Please check your dependencies on fgl
Ivan Lazar Miljenovic schrieb: > We considered giving it a new name (fgl', etc.) but figured that in the > long term this wouldn't be advantagous. We feel that the situation is > analogous to QuickCheck: when the new version came out most people kept > using the old one until slowly the momentum shifted and more people > started using the new version (without checking in depth, Roel's Hackage > mirror reports QC-2.x now has 153 reverse dependencies as opposed to 127 > reverse dependencies for QC-1.y). > > If we changed the name, then the "emotional attachment" that the Haskell > community has to FGL being the de-facto graph library means that people > would keep using the old version. Whilst we also face the possible > problems of people not liking the old version and thus automatically > dismissing the new version, I think this is a much more unlikely > scenario. I'm afraid you'll destroy the "emotational attachment" to fgl by annoying incompatibilities (and possibly interfering new bugs). Although parsec-3 can be used as an replacement for parsec-2 it would have been better, they had different names (as argued elsewhere for the haskell platform). Changing a dependency in a cabal file is a small problem. Those (unaware), who only mention "fgl", will fall over an incompatibility (usually at installation time!) and simple say "fgl < ..." unless they are willing to change their code then. Those who already have "fgl < ..." need to find an advertisement of a "new and better fgl" anyway and can choose when to change their code. Christian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
