
On 2008 Sep 10, at 18:43, Duncan Coutts wrote:
On Wed, 2008-09-10 at 18:35 -0400, Brandon S. Allbery KF8NH wrote:
On 2008 Sep 10, at 17:51, Duncan Coutts wrote:
dependent packages don't get confused when it's re-released. If we're considering modifying hackage's versioning, we should probably decide if we want/need this now instead of having to add it in later when something major goes *boom*.
We've thought about this and we think we do not need epoch numbers since we're in the lucky position of doing the upstream versioning.
Are we? I think the package author has final say if a package needs to be backed off, and any packages released between the rollback and the next release with dependencies on the backed-off package will be problematic, no matter how draconian hackage's version checking is. (This is a different situation from datecode versions as in the trac ticket.)
I'm not quite sure I follow. Certainly it's the author/maintainer who decides the version number. It's up to them to pick it, but they know the ordering of version numbers.
As I understand it, epochs were mainly introduced to cope with un-cooperative upstream maintainers whereas here maintainers already have to specify a version number in the Cabal/Hackage scheme and there's
That is one use. The far more common use, at least in FreeBSD ports, is when a version of a port has to be backed off; if any subsequently released packages depend on the backed-off version, things get nasty when the port is re-updated later. This may not involve the port author; it could be an unexpected interaction with an updated dependency under certain circumstances. "Backed off", in the FreebSD context, means an older version of the port is restored from CVS; in the context of Hackage it means removing the broken version and making the previous version the current version. Basically, you *do* have control over this... but it's possible for the effects to propagate rather widely before such an interaction is discovered, resulting in needing to revise either many packages to reflect the corrected dependency... or updating one epoch. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH