You can clone with
HTTPS or Subversion.
(Imported from Trac #265, reported by guest on 2008-04-08)
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.
(Imported comment by @dcoutts on 2008-04-08)
Perhaps we should just deprecate it and add a field for the api versioning scheme, like the package versioning policy.
(Imported comment by guest on 2008-04-18)
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'.
(Imported comment by @dcoutts on 2008-05-02)
Ah, I mean something like the 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.
(Imported comment by Isaac Dupree on 2008-05-03)
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@… fixes. "mostly dead" is not necessarily a bad thing or a bad description :-)
Closing as there's been no activity in years.
We're cleaning up the bug tracker to make it useful again and are thus closing bugs that haven't seen any activity in a long time. Please re-open (or file a new bug) if the problem reappears.