Lately I've often thought that the versioning policy only addresses half of the problem: the API. While it completely neglects the "other side" of the package surface: the dependencies.
I should probably mention that this springs from my work with packaging Haskell for ArchLinux and to be honest I'm not sure it's a worthwhile goal for the community to put much work into simplifying the work of distro packagers. Anyway, I think it is worthwhile thinking about and explicitly stating what the goals and non-goals of the versioning policy are. If the following statement would hold, then my work would become a bit easier: If I have a set of packages where all dependencies are satisfied, then it should be possible to update any of those packages to a new minor version (e.g. from X.Y.Z to X.Y.Z+1) without any further updates. I believe the following rules would help achieving that: - Use dependencies that are insensitive to changes in minor versions as far as possible. - Increase the major version if the lower bound of a dependency is adjusted up to a new major version. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
pgpGU5U3mKCJj.pgp
Description: PGP signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
