search

williamkapke / mongo-mock

Let's pretend we have a real MongoDB
MIT License
240 stars 74 forks source link

Merge Policy #74

Open angelo-hub opened 6 years ago

angelo-hub commented 6 years ago

Before we merge any of these new PRs with our new maintainers and get this project going, I'd like to implement a branching release strategy like gitflow into this project, I'd like to have feature branches for release tags to keep our semversion-ing in place with more maintainers coming on board, and feature build outs.

For example: I think bulkOps #67 and #63 should be held off and included in version release 3.4.0 while some of the patch PRs should be in 3.3.1, and therefor for major and minor semversion's I'd like to point PR's to a release branch, so we can make sure the additional features are well tested together before publshing.

@Pidid what do you think?

pstromberg98 commented 6 years ago

@AngefloMusic Yeah I think this makes a lot of sense, and really like the idea of using gitflow. And just so I understand correctly, are you saying that our feature branches would be like "v3.4.0" and any major feature pertaining to 3.4.0 will be a PR under "v3.4.0"? So if we were following this pattern from the start, bulkOps #67 and #63 would be PR's under the "v3.4.0" branch instead of master?

angelo-hub commented 6 years ago

@Pidid Yes exactly my point, I just didn't want to start doing it without a discussion within the maintainers

pstromberg98 commented 6 years ago

@AngefloMusic Yeah for sure! Well I'll start following this pattern and I am assuming to make pull requests to "v3.4.0" for any features moving forward. Should we make a contributor guide that details stuff like this merging policy?

angelo-hub commented 6 years ago

Yeah we should, i’ll start writing a contributor guide, and put a PR in for it this week

zardilior commented 5 years ago

@AngefloMusic lets also open a slack shouldn't we for contributors etc!!