@hrajagers wrote: >The branch per "release" approach might make it conceptually a little bit >easier to start working on a draft of "release 2.0" while also working on an >earlier "release 1.8".
Agreed -- master should be for the current "working version" -- i.e if 1.8 is out, changes that will be in 1.9 go in master. In the usual case of software, you have a "current release", say 3.2 (choosing examples that aren't currently used for CF), and you are working on 3.3 in master. Meanwhile, if you are maintaining older versions, say 3.1.3, you might do bug-fixes on that, and release a 3.1.4 -- in which case, there is a branch for 3.1.* where the bug fixes go. In the CF case, we don't have to fix bugs in older releases, so it's easier. The one complication is if we have a "future" version that wont' be released for a while -- that would be 2.0 for CF -- so that should be in a separate branch -- or maybe a separate repo altogether. I jsut took a look at the cPython repo -- for an exampel of a major project: https://github.com/python/cpython The currently have: 2.7 3.4 3.5 3.6 3.7 master 3.7 is the latest version -- they are working on 3.8 in master, and 2.7--3.6 are in maintenance mode (i.e. just bug fixes). -- 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-412938879
