There seem to be two ways people develop in Git repos: 1. Develop in "master", and branch/tag stable releases -- this is what we do, and we name release branches RB-x.y and tag specific releases Release-x.y.z, and we also have a branch called "release" is moved around to always point to the latest approved release tag.
2. Have "master" always point to an approved release (replacing our current "release" branch label), and have a "dev" branch that is the top of the development tree. So a release consists of moving the "master" marker (and/or merging dev into it). We've always done #1, which I think is very convenient for developers -- it lets us maintain a nearly linear history, no confusing merges, and also it means that by default a developer checks out the dev tree and posts PR's against it. But many projects seem to prefer #2. I think that's an extra burden on developers (who need to work in the dev branch and be careful that their PRs are posted against that one), but it's a lot easier for new people to check out and build the project, because the default "git clone ..." will give you master, which for this scheme will always be the latest stable production release. There's no rush about this, but it's something I occasionally think about. If you have strong opinions, feel free to share. I have no particular reason to change, but if the overwhelming consensus is to prefer #2, I'm ok with that. -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
