Discussion -- Pull Requests and Branches
Closed this issue · 6 comments
This is intended for community discussion
As an open-source project, the Compliance Checker gets lots of useful PRs from a variety of contributors. Most of these PRs go straight to the master branch, and typically public feature branches are used for adding large features, such as new checkers, API changes, etc. With more activity as of recent, I believe we should move towards locking master to the latest release and having a permanent development branch. This way, we can ensure no confusion when merging PRs that may not directly relate to a specifically planned milestone. Thoughts? @benjwadams @Bobfrat @ocefpaf @neumannd @mwengren (feel free to tag anyone I might have accidentally missed, just picked the few top 'Review" suggestions)
I'm fine with that. Although I'm more used to a slightly variation of that model where master is the development branch and a versioned branch be the "locked" release one.
I'm not very experianced in participating in open source projects. Sounds reasonable to split up the one master branch into a development and a release branch. Maybe it leads to less confusion/errors of new contributors if the master is kept as development branch.
I'm also good with this. I've seen both what you describe with a develop/master branch and what @ocefpaf describes (master/stable). I'm ok with either as long as its very clear in a contributing.md file or similar. Also tagging some OG's @lukecampbell @daf @kwilcox
I've never used an active develop branch on a project before, but sounds like a reasonable plan. There wouldn't be any major workflow changes it sounds like. New release functionality goes into develop (or master depending on the names chosen) and master|stable is kept to match the most recent release?
Major new changes not planned for the next release (such as an API change perhaps) would still go into a 'feature' branch?
I'm a little late to the discussion, but from my experience most github repositories rely on the master branch being the unstable development version, since pull requests default to master, and master has been historically used as the development branch. It's more common, in my opinion, to create separate stabilized branches from master and pull in features, or version release candidates from the master branch, and once the release is ready a tag is made from that branch.
There was some major overhaul to the compliance checker back when the CF 1.7 checker was under development which may have prompted this discussion. However, I'm in favor of keeping the development version under master, but creating PyPI and Conda releases for stable, tagged commits on master, and maybe leading edge builds as well if it can be set up with CI. Closing and sticking with the current status quo. If we want to release more "bleeding-edge" compliance checker versions as Python packages, that can be discussed in a separate issue.