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". If you want to just have a tag "release 1.8" then you will have to either postpone the work on "release 2.0" until a later date (not recommended) or to create a branch for the long-term developments (a common approach). One way or the other you'll need to merge changes between branches. I think that working on the "master" for the earliest upcoming release and having development branches for bigger more distant release is the most common approach in software development, and helps you to avoid losing (small) updates in the current version. However, if you expect future updates to earlier versions (e.g. a "release 1.9" after the major update "release 2.0" has been released, then it may be pragmatic to immediately organize the system with a branch per 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-412931776
