> standard tagging practice supports this without any difficulty in a single repository.
Judging by our comments I suspect we have different perspectives on "standard practice" for tagging and branching. Perhaps you could elaborate on how you would see it working?
The nice thing about having a single versioned "thing" (which might be comprised of many, many files) in each repo is that it is easy to manage fixes to previous versions. By creating a new branch for each major/minor version it is a simple matter to apply "bug fixes" (e.g. spelling corrections, typos) to prior versions and bring those corrections into the subsequent versions. It also makes the stream of releases/tags simple to scan. (e.g.
https://github.com/numpy/numpy/releases).
Placing multiple "things" in a single repo and using a branch for each "thing" doesn't play nicely with that approach. The stream of releases becomes harder to read (e.g.
https://github.com/UV-CDAT/uvcdat/releases?) and the inter-dependencies are more ambiguous. Managing bug fixes to prior releases becomes tricky, unless the "thing"-branches have no content in common. But in that case the model is pushed so far that it's effectively emulating separate repos. This has undesirable consequences for the ability to transfer git/github skills. Why emulate separate repos when you can have the real thing?
Richard
Received on Wed Sep 24 2014 - 04:14:16 BST
