Jan Engelhardt (jengelh@inai.de) wrote:
On Tuesday 2013-09-10 15:39, Adam Spiers wrote:
Exactly. Even for a project that strictly follows semver, it still might have a series of tags like this:
v0.1.0 v0.1.1 v0.1.2 v0.2.0 v0.2.1 v0.2.2 rel-1.0.0 rel-1.0.1
semver does not cover *version-unrelated* prefixes/postfixes.
That was exactly my point.
If the developer of the particular software whose tags you have presented really had a change of heart and went from "v*" to "rel-*" for whatever reason, you, as the packager, should have been smart enough to recognize this and _NOT_ transplant the v*/rel-* into the RPM Version: field, just like it is done for the Linux kernel (has tag like "v3.11" but our RPM packages have 3.11 naturally). In fact, blindly transplanting whatever `git describe` tells you into Version: is almost
... almost what? But it sounds like you are making the same point I already made - git describe output is not a remotely reliable source for version ordering. The timestamp + SHA combination is deterministic and unique, sorts chronologically, is well proven (my team has been using it for 18 months), and is trivially supported by tar_scm, e.g. <service name="tar_scm" mode="disabled"> <param name="url">git://github.com/foo/bar.git</param> <param name="scm">git</param> <param name="exclude">.git</param> <param name="exclude">.gitreview</param> <param name="versionformat">1.2.3+git.%ct.%h</param> <!-- Comment this if you want the latest git master. --> <param name="revision">stable</param> </service> If you know you can trust your git tags then it can automatically extract those as the "parent" version string too, e.g. https://build.opensuse.org/package/view_file/Cloud:OpenStack:Master/openstac... The only remotely convincing argument I have heard against timestamp + SHA so far is that it generates long version strings which may cause problems with Joliet filesystems. Yes, they can also make a UI slightly uglier, but if that's a genuine issue (which I doubt) then it is trivial for the UI to trim the version components. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org