Alpaka: Rename develop branch to master

[BenjaminW3]

It is now a few months ago since I deleted the master branch.
My intentention was to simplify the branching model from a gitflow-like model:

• develop - active development
• master - last release (regularly updated from develop)
• release-branches/tags - releases

to

• develop - active development
• release-branches/tags - releases

The reason for this is that users do not have any advantage of separate develop and master branches. Both can have breaking interface changes at any time. If users need interface stability they have to use release-branches/tags.
On the other hand it makes our live easier if there are no two branches that have to be synchronized. We should not see develop as a branch where unstable features are merged in. All the features we add should be releasable at any time. Therefore develop should be releasable at any point in time. This makes it similar to what master was. If there really is a bug we can revert the change or fix it and create a new release.
More reasoning to simplify the branching model can be found here:
https://reallifeprogramming.com/git-process-that-works-say-no-to-gitflow-50bf2038ccf7

I would now move on to the next step and rename the develop branch to master. This is only a cosmetical change that is necessary because most tools and developers are more used to the name master as default branch.

[BenjaminW3]

@ComputationalRadiationPhysics/alpaka-maintainers Any objections?

[sbastrakov]

I like the reasoning in the linked article. Also recently had several encounters with ppl being confused about picongpu master and dev relationship (and also lack of master in alpaka).
@psychocoderHPC @ax3l what are your thoughts on that?

[ax3l]

I fully agree and matured to the same conclusions as @BenjaminW3 .

I think a "stable" branch has no real use case since one can always branch from tags to set up new release-... branches until a new tag is set. Inexperienced users should not git clone anyway but use a package manager or fixed tags. Developers should get the development branch by default for clone and PRs.
(Read as: PIConGPU should remove it's master branch at some point, too. Don't forget to update it's CONTRIBUTING.md docs when doing this.)

One idea: I do like to call the active development branch develop to make clear what it is (instead of naming it master). But I generally dislike the master terminology anyway.
(Read as: I think keeping the develop branch in Alpaka is good, we don't need to call it master which has no unique meaning anyway.)

[fwyzard]

Well... quoting from the same article:

Everybody in the world expects to see latest changes in master after they clone your repo. Every tool out there considers master as the current development branch.

[psychocoderHPC]

I am not a friend of this master is the development branch model. If someone is coming to our github starting page you have a prominent green button Clone or Download where you can download the code as ZIP or get the link to clone the project.
After cloning or downloading you have the development version of a project. If I like to test a project I do not like to start with a non-stable version for my firsts tests because the first impression often counts and we know that our development branch is mostly working very well but the possibility that something is broken is IMO higher than on a stable branch.

I am ok to keep only one branch develop, what we currently in alpaka have and what @ax3l suggested, to clearly mark that the branch presents the ongoing work. I do not agree with the motivation from the article to name the development branch master only because the tools assume that there is a master branch but since I never used a GUI for git I have no git overview without the git command-line tool.

[ax3l]

Well... quoting from the same article:

Everybody in the world expects to see latest changes in master after they clone your repo. Every tool out there considers master as the current development branch.

Sounds a bit totalistic in the article to me and is actually not true. Git flow as well as package mangers such as Spack tagged versions are counter-examples of how things are already named in many projects and where "current" code can be obtained from. I am very much with René's point of view, just keep it explicit instead of assuming everyone knows or researches a repo's development model when visiting it for the first time.

The only thing I do expect (on GitHub) is that the default branch is the development branch that accepts PRs, because VCS is developer centric and no replacement for a deployment workflow to users.

After cloning or downloading you have the development version of a project. If I like to test a project I do not like to start with a non-stable version for my firsts tests ...

Then you should go to "releases" and download a version that does not read develop in its title, left of the green botton.

I don't think users that are not aware of VCS should obtain quality code via git clone anyway, as mentioned above, but should use artifacts (see: releases), ideally via package managers.

I am ok to keep only one branch develop

yes, I think that makes it less confusing for exactly the point you mentioned. We very much follow the development model of the article, but name our default branch explicitly develop to circumvent that one has to acquire any tribal knowledge.

[fwyzard]

I do not agree with the motivation from the article to name the development branch master only because the tools assume that there is a master branch

The motivation is not "because the tools assume it" but "because the vast majority of developers assume it".

So the choice really boils down to whether one gives more importance to personal preferences or to making it easier for other people to contribute.

As a possible user I won't mind much either - I care much more about things like the next stable release out so I can actually test it, since apparently I am not supposed to get the code directly out of git.