[Hackage] #265: Cabal field stability not useful
#265: Cabal field stability not useful ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- As it stands, the 'stability:' field isn't very useful. Hardly anyone uses it, and even if someone does, it does minimal good, since it's just an arbitrary string. I propose it be changed into an enumerated type, like license: is. That way we could do things like have cabal-install warn when installing unstable, add view filters to Hackage, and so on. This is all stuff that'd be pretty ad-hoc if done on whatever strings package authors were writing. Now, what should the entries be? Ideally, we'd like to be able to say a couple things. We'd like to say that a release is Stable, or Unstable. For example, HaXml's most recent package on Hackage is Unstable, and that's why Goerzen's Hpodder uses an older, Stable, version of HaXml. But we'd also like to express not just stability, but feature-completeness - Alpha, Beta, Release. It's perfectly sensible to have a piece of software which is a Stable Alpha; early XMonads were very stable (I was using it from the first public repo patches, and it only ever crashed a handful of times, less than StumpWM). And equally I'd suggest you could have Unstable Betas. Most cabal files I've seen using stability: seem to use 'Stable', 'Unstable', 'Experimental', 'Alpha', or 'Beta'. (Although GTK2HS seems to be using 'Stability: provisional'). So perhaps one could make the stability field accept 0-2 entries: one from Stable/Unstable, and one from Experimental/Alpha/Beta/Release. -- gwern -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/265 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#265: Cabal field stability not useful ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Perhaps we should just deprecate it and add a field for the api versioning scheme, like the package versioning policy. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/265#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#265: Cabal field stability not useful ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by guest): I don't entirely follow; since it's not being used much, or for any particular purpose, deprecation isn't a bad idea. But I'm not exactly sure what you mean by 'a field for the api versioning scheme'. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/265#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#265: Cabal field stability not useful ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Ah, I mean something like the [http://haskell.org/haskellwiki/Package_versioning_policy package versioning policy]. It would be useful for packages to opt-in and declare that they follow the versioning policy. It provides similar information to the stability field but it's more precise and more useful. It also gives us the potential to check that packages that following the versioning policy really are doing so. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/265#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#265: Cabal field stability not useful ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.3.0 Severity: minor | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * priority: normal => low * severity: normal => minor * milestone: => _|_ -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/265#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#265: Cabal field stability not useful ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.3.0 Severity: minor | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by guest): * cc: gwern0@gmail.com (added) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/265#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#265: Cabal field stability not useful ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.2.3.0 Severity: minor | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by Isaac Dupree): It's easy to measure feature-completeness before release. It's reasonably possible to estimate stability before release, though it can always become more or less stable than you expected (especially with different compiler versions?). It's nearly impossible to determine whether critical security flaws will be found in a release of software, which should certainly be marked for any version of a package that has those flaws. Some of these things should ideally should be marked (on Hackage?), separately from the actual tarball / .cabal, because that obviously can't be amended for a version that already exists. As for words: "Unstable" could mean that there are likely to be breaking changes in the interface... or it more likely refers to likelihood for that particular version to have bugs. And then Alpha/Beta/etc. conflates feature-completeness and interface stability? Well, at least those tend to go together in good software development... or not, considering Data.Map etc. still getting libraries@h.o fixes. "mostly dead" is not necessarily a bad thing or a bad description :-) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/265#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (1)
-
Hackage