We started using Github a few years ago for a project I work on. It was decided at the start that changes should go onto master frequently, and that we would simply tag master for the major release versions. It didn't work in practice, because near release time there were divergent needs within the project. Some people wanted to only allow changes to master that were for finalizing the release, while other people needed to keep working on future capabilities. If finalizing the release only took a couple of weeks this wouldn't be a big deal, but big releases often takes months to finalize (CF tends to spend a lot of time agonizing over the details too). I think this is the issue that @dblodgett-usgs mentioned in his last post (above). However, I don't see it explicitly mentioned in the 4 bullets.
There are two ways I can see this working near release time: (a) master is for the release version and future changes go onto one or more feature branches that get merged to master after the release, or (b) vice versa, ie the release on a branch and the master keeps developing. In my project we ended up doing (b), but it would probably have been better to do (a). In any event, I think it would be good to add a fifth bullet to the list of @dblodgett-usgs that clarifies how master and branches will be used near a release. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-413023840
