RFC use master branch as the development branch

[lucascourot]

At the moment prooph repositories use a gitflow-like workflow which means all the feature PRs should be merged into develop and all the bug fixes should be merged into master. The master branch only hosts the releases and always reflects the latest stable version.

When it may look more robust at first glance, it actually feels to me confusing and counterproductive.
Here are some of the drawbacks I see:

• This is not what most Github contributors are used to. When creating a new PR, as an OS github contributor, I'm used to use master as the base branch, respecting the Github workflow. This is the first point of confusion. And doing a quick search on proophessor-do confirms that contributors don't always know if they should chose develop or master as the base branch (#51, #66, #71, #84, ...).
• In our current workflow, we merge develop into master and from time to time we merge master into develop for being sync which adds some noise to the git-log tree.

| * |   b5f8ea3 - Merge remote-tracking branch 'origin/develop' (2 months ago) prolic
| |\ \
* | \ \   036b92a - Merge remote-tracking branch 'origin/master' into develop (2 months ago) prolic
|\ \ \ \
| |/ / /
| | / /
| |/ /
|/| |

• The release process is heavier and features seem to take more time to be merged into master as they are all merged at once. The result is a big PR which is difficult to review. For proophessor-do it might be interesting to release often (one exercice = one PR = one release), similar to continuous deployment.
• For projects like prooph/event-store it might also be interesting to have one maintenance branch by release, just like symfony/symfony does.

I would like to have your point of view on what you think of the current prooph's git workflow and how we could improve it. I'd suggest to remove the develop branch and make all the futur PRs against the master branch.

Would it be more natural/easier for you to have master as the develop branch? Shall we add release branches for maintenance?

[prolic]

I am for keeping master branch for bugfixes and develop branch for new features.
But there will be (f.e.) an event-store v6 branch which will be supported until end of 2017 for bugfixes in the 6.x-series. No new feature will be developed for 6.x-series.

[nealio82]

Having worked with both git-flow and github-flow methodologies, the former is much more restrictive as a workflow and lends itself to delayed releases, feature rot, and merging issues (although perhaps that was down to the way we were using it at the time, with features being too large and project management sporadically being applied). Regardless, github-flow has proven much more flexible for our teams and makes continuous deployment far easier.

[codeliner]

I'm not sure. CD is great for applications but I don't know if it is a good fit for OSS libraries. Anyway, if contributors are more used to the github-flow it would be ok for me if we use it. I wasn't aware that so many github projects use the github-flow. I'll think about it and add my thumbs later.

[rommsen]

I am all for this change (we use git-flow for our project and it works good, but I think its different in oss stuff). Just go through the PRs not done by @prolic or @codeliner and see how often you had to ask to make this PR against develop and not master. Its always a hurdle for newcomers.

[prolic]

PR to wrong branch is not such a big deal anymore, as github allows now to change the base branch after the PR is created.

[codeliner]

I voted for the change, too. Yesterday I was asked: Where are the new features presented at the prooph meetup? My answer: in the develop branch of course.
But I'm starting to realize that things have changed. It seems that people expect to find latest changes in master. That is a good movement, because continuous delivery works this way. Yeah and maybe continuous delivery can also work for OSS.

[basz]

I am familiar with git-flow - not with github-flow. so no preference... i'll 'go with the flow' :-)

[sandrokeil]

I'm flexible too and it can simplify things. A branch for experiments or long running features can also be exists. It's only a name.

[codeliner]

For some component repos we switched already, but I'm not sure atm if this is true for all repos. We should add a contribution.md to all repos with always the same rules and the github-flow.

[sandrokeil]

Yes, maybe we should create a maintainer repo like zend to put some guidelines there.