On Dec 17, 11:36 am, Tekkub <[email protected]> wrote: > Sorry, I was a bit unclear... by "feels lazy" I meant, if you're creating a > tag then it seems logical to me that the version should be the tag name... > and that you'd use some sort of standard versioning scheme for that > (major.minor.patch) that would be human-readable. I've seen far to many > (svn) people that use the commit number *as* their version number. Not just > build number, as the whole version. Naturally that makes even less sense in > git, since commits are not sequentially numbered. If the user is using a > nightly-build or "edge" sort of setup, then SHA1s would make sense. Simply > put, if the end user is not aware of git (they're using a tarball instead of > a clone), then I would expect that the packager wouldn't be either. > > As for the contents of the tarball and the variables, you'd probably be best > to direct those questions to the git mailing list. We just use git-archive > to create the tarballs, and git doesn't have a variable system like svn > does. >
okay that makes sense. i can live with "hashes for git users, tags for release users", but again: once you got the tarball from github there is no way to know which git tag it corresponds to. this is really too bad, as you need to resort to workarounds such as manually updating versionfiles in order to support normal downstream packaging. Dieter -- You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/github?hl=en.
