On 11-Jun-2016, Ben Finney wrote: > I think the suggestion was to have a version scheme for each > separately-released project: if it gets released on its own > schedule, it gets its own (single, monotonically icreasing) version > string.
Now that we have the following versions upcoming: * Inform 6 compiler version 6.34 * Inform 6 library version 6.12.1 it is clear their versions are distinct, and ‘inform6unix’ should not attempt to track either of them directly. Can we have the ‘inform6unix’ code base also use a clear, semantic versioning scheme <URL:http://semver.org/>? I would recommend the scheme adopted until recently: The ‘inform6unix’ code base gets a semantically later version than the Inform 6 compiler release that it complements, but earlier than any expected future release of the compiler. * So the “6.33-6.12.1” release is out of sequence (and I'd ask that it be removed or renamed), and instead the version “6.33.1” is appropriate. * For a putative upcoming ‘inform6unix’ release that complements Inform 6 compiler version 6.34, the version “6.34.1” would be appropriate. Followed by “6.34.2” if needed, etc. That would allow an easy way to compare ‘inform6unix’ releases and know, just by the version string, which one is later. -- \ “If you were going to shoot a mime, would you use a silencer?” | `\ —Steven Wright | _o__) | Ben Finney <[email protected]>
signature.asc
Description: PGP signature
