On Thursday 18 October 2007 21:15, you wrote: > Daniel McAllansmith <[EMAIL PROTECTED]> writes: > > 3. Otherwise, major.minor MUST remain the same (other version components > > MAY change). > > Is it an option to say SHOULD rather than MUST here?
Of course, SHOULD is an option just like MAY is. But both SHOULD and MAY reduce what you can reliably infer from a version number in the same way. If the rule is SHOULD or MAY, and the freedom is exercised, compatible versions of a package will differ in major[.minor] and dependent packages will be unable to benefit from their release. You'll need more maintenance work on package dependencies if you want to use the latest and greatest versions. In a similar way, if packages are being retained for a 'long time' to ensure dependent packages remain buildable, you are losing garbage collection opportunities. I'm pretty certain SHOULD will be far more socially acceptable than MUST. I can appreciate the fact that people are accustomed to incrementing version numbers in liberal ways. But if you look at version numbers dispassionately in the context of "The goal of a versioning system is to inform clients of a package of changes to that package that might affect them..." MUST seems a better choice. Maybe the Right Way of informing clients is full-on metadata and typing of packages and maybe we'll have that soon, so maybe a socially acceptable, weaker versioning scheme is acceptable. > There are > other reasons for a version bump than breaking compatibility. Technical reasons? In some cases a major bump would just be devolving to a minor bump. Dan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
