This is definitely the most natural way to work on GitHub and very git-native, which I like. However, I do think there is merit in having a `next` branch. Because CF isn't software that we're releasing with continuous delivery, having fewer, but larger, changes between versions is probably the better way to go. It also better reflects the understanding achieved at the meeting - namely, that `master` is basically a release branch, and that the draft (whether named `next` or something else) collects changes before merging them all into `master`.
Concerning the workflow @ajelenak-thg outlines - that's certainly the way I intend to work, but my feeling is that we'll perhaps need to have a bit of patience with people who are new to both git and GitHub as they get used to it, so we shouldn't be too strict with enforcing the specifics of that workflow. So the only point of ambiguity for me is the branches. I do think that having `master` only be merges with tagged releases has advantages for novices - even though you can achieve the same amount of traceability by only tagging releases, and declaring intermediate commits on `master` as transitionary, I think that having non-tagged releases appear as the repo's landing page could be confusing to some of our contributors. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-399350001
