Drop dual master-develop branching in favor of a single prod branch

[PeterBowman]

I've come across an interesting article: https://towardsdatascience.com/git-flow-is-the-source-of-productivity-not-confusion-8abda7c5fb30. It is stated that two common workflows are encompassed in the so-called git-flows:

Scenario 1. You need a fast development process with frequent releases. You do not want to have a gatekeeper to sign off releases. You accept to accidentally introduce minor bugs into the master branch without causing the main functionalities to stop. Plus, you do not need to have control over the feature list in each release.

This corresponds to a High-Frequency and Low-Quality development cycle: master branch plus feature/bugfix branches stemming from and merging directly into it.

Scenario 2. You have a relatively large number of users. You must extensively validate the quality of the product before each release. You want to have a team that constantly reviews the product, and a gatekeeper to sign off releases.

In turn, this one is defined as the Low-Frequency and High-Quality case: master branch (we call it develop) plus release branch (that's our master). The former is the entrypoint for all development, and it is occasionally merged into the release branch by a "gatekeeper".

So far, we have widely adopted the convolute dual-branch workflow (master+develop), see e.g. roboticslab-uc3m/yarp-devices#34. Doubts arised upon considering documentation-like repos: roboticslab-uc3m/developer-manual#6. Still, every other repos (particularly the source-code ones) must currently adhere to the second scheme: roboticslab-uc3m/developer-manual#16.

We are not confident enough in creating releases of our source code. Note this is not a straightforward process, it needs some special care and synchronization due to interdependencies across a few of our own org repos. That case was supposed to fall into the scope of YCM superbuild usage scenarios: #1. We've never fully exploited this feature, though. YCM is rarely or never used in that way in our ecosystem, we'd rather build each repository separately and then install and link as usual, no special orquestration involved.

The Low-Frequency and High-Quality is better suited for bigger projects, such as YARP. Proposal: let's drop the dual master-develop branching system in roboticslab-uc3m (unless specifically justified, see amor-api) and resort to a single master branch. In practice, it means that what we call develop should become master.

[jgvictores]

IMHO yes, I agree. Our current workflow does not benefit from the master/develop branches. In fact, all we get is a very old master branch which we update when we remember and it looks outdated (a criterion that results in very arbitrary dates and circumstances).

[PeterBowman]

So, do we all agree on this? Pinging @David-Estevez per #7 (comment), among other issues.

[David-Estevez]

LGTM!

[PeterBowman]

To sum up, at the time of writing this we follow the gitflow workflow approach almost everywhere (documentation-like repos aside). It is proposed to perform a paradigm switch by adopting the forking workflow instead.

Next steps:

• edit and update: README.md, CONTRIBUTING.md, travis.yml
• merge develop into master
• in GitHub, set master branch as default and enable protection
• in travis-ci.com, schedule cron jobs to target master instead of develop
• just in case, also in travis-ci.com: delete develop branch cache files
• drop a comment in [github] Mention setting develop as default developer-manual#16
• poke everyone in this org about the ongoing changes and the following point
• delete the develop branch (in a week or so, let's see)

Edit. Since not all repos will be referenced by commits below this comment, I'm listing them here:

• color-debug
• asibot-configuration-files
• amor-configuration-files
• teo-configuration-files
• data-visualization
• bullet-yarp-plugins
• jr3pci-linux
• openrave-tools
• textiles
• WBPCwaiter
• robotDevastation-openrave-models

[PeterBowman]

cc @roboticslab-uc3m

Most or all org repos will undergo a significant change in the branching logic. The pair master & develop will cease to exist in favor of a single master branch, following the Forking Git workflow. In the next few days, there will be no more a develop branch, so please stay tuned/calm and git checkout master && git pull. Existing feature branches should merge or be rebased against master.

[PeterBowman]

This is all done. The announcement was made here: #88 (comment). Recap: please switch your local repositories to master (git checkout master) and pull latest changes (git pull). Your local work should be merged into the master branch, there is no develop any more.

[jgvictores]

@PeterBowman Thank you so much for all of this!!

[jgvictores]

PS: Ran into warning: ignoring broken ref refs/remotes/origin/HEAD a couple of times. Via https://stackoverflow.com/questions/45811971/warning-ignoring-broken-ref-refs-remotes-origin-head, solution adapted from kdechant (refer to SO for alternatives):

git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/master

Edit by @PeterBowman in order to make this show up in search results: (refs/remotes/origin/HEAD has become dangling).

[PeterBowman]

I have just switched branches in robots.uc3m.es in order to generate doxygen files for master instead of old develop.

[jgvictores]

@PeterBowman thanks a lot for this!