kkremitzki wrote:Let's say I'm a committer and I want to push the newest version of 0.16. I can run the following commands:
Code: Select all
g tag -f 0.16 # force updating
g push origin :refs/tags/0.16 # delete on remote
g push origin 0.16 # push tag pointed at new commit
Please NEVER EVER change published tags. Other users that have already cloned the repository will not receive the changed tag. They will continue to keep the old one and everyone involved will be confused. Yes, that includes the developers as well. Also see: https://git-scm.com/docs/git-tag#_on_re_tagging
Also after maintaining the Arch Linux freecad package for two years, I finally learned that freecad apparently does more than one release per year. Please just do what git, and anyone who knows git, expects you to do and tag them properly instead of changing the tarballs on the github page. You could just tag them with something like 0.16.1234. That way I get notified because the github rss feed shows a new release and you don't have to wonder which versions people are using when they say 0.16 because there is only one 0.16 tag and the others differ. Obviously you'll still have to update the version information before tagging the release.
If you want to know how that looks, take a look at the linux kernel:
https://git.kernel.org/cgit/linux/kerne ... /refs/tags
I'd also suggest that you look into semver, but that might be a bit too disruptive for now: http://semver.org/
PS: Please set up HTTPS. Getting certs is free now thanks to Let's Encrypt.