I'd like to propose the following as a versioning strategy and write it up in the wiki before we start on the next release cycle. Any objections?
* Adopt Semantic Versioning[1] syntax, and its bumping and comparison semantics without stating that we conform to it. We're beyond 1.0.0 for historical reasons, but we don't really have a notion of a hard public API yet and I'm not sure if that matters. * The code itself (gui/main.py) should record a base version having one of the forms 1.1.1-activedev ← development cycle for 1.1.1, major refactors permitted 1.1.1-alpha ← alpha release cycle: regular prerelease builds, no major refactors 1.1.1-rc ← release candidate cycle: feature freeze in place 1.1.1 ← the release commit itself (and only that commit) 1.1.2-activedev ← the very first post-release commit begins the next release cycle * If we need a beta cycle, scope exists for that. * Only one commit on master ever has an unadorned base version. This is the one that gets tagged in git. * If releases are to be managed on separate branches, scope exists for that. Ditto for the formation of temporary active-dev branches during freezes. * The release script (release.sh) should be updated to append a "." and the current YYYYMMDD-format date if it is being run to make a prerelease version. This generates 1.1.1-activedev.20140310 1.1.1-alpha.20140401 1.1.1 * It might be bad practice to release more than once per day in any given pre-release cycle, but if that's necessary we can append ".1", ".2" etc. for disambiguation. * The build scripting (SConscript) and the release script should be updated to append a "+git" and the current short form (7 hex-digit prefix) of the git head, if the build or release is happening within a git repository *and* when the build or release is a pre-release. These *very* long versions are to be exposed in tarball names and in the app's about box, e.g. 1.1.1-activedev.20140310+git77749db 1.1.1-alpha.20140401+gita84ceb2 1.1.1 * This scheme can be transformed to Debian and Ubuntu "upstream" revision coding[2] by substituting a "~" for the "-". This is required because Debian and Ubuntu reserve the minus sign for their own purposes, and tilde has the comparison semantics we need. Making a string that can fit into SemVer and Debian sort semantics with minimal rearrangement and without requiring any numeric-part hacks would be a Nice Thing, and that's why I'm suggesting "activedev" for the active development cycle. For completeness, Debian and Ubuntu *full* version numbers might look like 1.1.1~activedev.20140310+git77749db-1 1.1.1~alpha.20140401+gita84ceb2-1ubuntu2 1.1.1-2 [1] http://semver.org/spec/v2.0.0.html [2] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version -- Andrew Chadwick _______________________________________________ Mypaint-discuss mailing list [email protected] https://mail.gna.org/listinfo/mypaint-discuss
