Rethinking official branches

[mrcasals]

I'm thinking about changing the current branch setup in this repo. Right now we have this:

• master: nobody pushes to this. It seems to hold the code of the latest gem version. Some versions are created from this branch.
• develop, the main developing branch. Most of the PRs go to this branch
• release/0.XX-stable the code for a specific release and all patch versions related to it.

To me, it seems that master is not really useful: if it only holds the code of the latest version, then you should be requiring the latest version in RubyGems. That's safer to everyone. With this, I think we can drop the current master branch as its used right now, we don't need it.

Now, develop can stay or can be moved back to master/rename it to main. I don't have my mind set on this, I'm fine if we keep develop.

Release branches (release/0.XX-stable) should hold the code used to generate patch versions. This means, release/0.23-stable should hold the code for v0.23.0 and v0.23.1 (this isn't currently happening, as the commit that holds 0.23.1 is actually on master). I've been checking the Rails repo, and that's how they do it.

So, my proposal is to drop the master branch, keep develop as it is and make the versions in their release/0.XX-stable branches.

Thoughts?

[Dynnammo]

I agree with you on the point that master is not used in the dev process. However, product managers and interested people may be confused by its absence, as master is generally the branch you pull first when you clone the repo and run Decidim for discovering purposes.

[andreslucena]

Actually this isn't like that. You can configure whihc default branch you want, in decidim our default branch is develop. You can check this out by doing:

git clone https://github.com/decidim/decidim/ 
cd decidim
git branch

master is generally the branch

This is a convention that's being discussed in the last year of so. See https://github.com/github/renaming

[oliverbarnes]

Personally I like what had been discussed earlier, dropping develop in favor of master/main, and cutting releases from that. Like Rails

[mrcasals]

I see both @Dynnammo and @oliverbarnes are on the same page, I don't mind renaming develop to main although it might break some workflows at the beginning, but it's not a big deal. I'd like @andreslucena's input too on this!

Some relevant PRs and discussions in #6460 and #5745, too.

[andreslucena]

I think there are two discussions here actually:

develop and master

To me, it seems that master is not really useful: if it only holds the code of the latest version, then you should be requiring the latest version in RubyGems. That's safer to everyone. With this, I think we can drop the current master branch as its used right now, we don't need it.

The idea of having develop and master was that master should be the last stable version; so for instance if I'm always pointing to master in my Gemfile then it should never break and I could upgrade from 0.22 to 0.23 to 0.23.1. This was proposed offline by @Jordi-Miro. In the other hand, develop is always in development, could and will change and break.

@Jordi-Miro, could you chime in?

This current flow is also consistent with git flow:

See also Git conventions doc and especially Releasing new versions doc where the current flow is defined. If we're changing this then we should also change the docs.

main and master

Related to this, there was an open discussion about renaming (although there were fears about possible breaking some flows). Also relevant what I've linked before of github renaming
I've also changed the default branch to main in some repos:

• https://github.com/decidim/demo.decidim.org
• https://github.com/decidim/decidim.org

Couldn't make the change yet at https://github.com/decidim/documentation as Antora didn't allow it easily yet (you had "main" in the URL of the generated site, I couldn't review that yet)

Regarding this other discussion (master and main) I strongly advocate in favour of main as you can see ;)

[mrcasals]

For me it's fine if we rename develop to main! @andreslucena are you OK with this? 😄

[andreslucena]

I don't have a strong opinion in this one actually, only that if we move to that model we should document that and explain the reasoning.

[andreslucena]

develop

• is what git flow proposes
• shows that's an unstable branch (in development)
• is what we have now so we don't have to change anything (aka the lazy and conservative argument 😅 )

main

• is what GitHub is pushing for so it's becoming the standard
• is what people expect: I suppose someone can come in and ask 'why you don't have a main branch?')

[oliverbarnes]

I get the path-of-least-resistance argument regarding just keeping develop. I'm lazy too =D

But I really think newcomers will be weirded out by a default develop branch, and as I said in previous comments, I think this branch should be stable, and PRs and reviews should aim to keep it so. Naming it main, which is the new master, will better signal that. People are used to respecting master more than develop.

I'd even remove "stable" from the release branches' naming, to further enforce that.

[mrcasals]

I asked around Codegram devs that have worked on Decidim at any time, and everyone seems to agree that main would be less surprising than seeing develop directly, so I'll work on changing this!

[tramuntanal]

I also am for changing develop to main and removing master.

The idea of having develop and master was that master should be the last stable version; so for instance if I'm always pointing to master in my Gemfile then it should never break and I could upgrade from 0.22 to 0.23 to 0.23.1.

In theory, it seems a good idea, but in practice installations are not always to the latest version. Usually, implementors should take care when to upgrade to the next version because the owner organization may prefer to stay in a stable branch (during a process for example) and would only want patches to their version. So, it is normal, at least for us, to change the branch from which an installation is pulling from one stable to the next stable. This keeps more control of the current Decidim version and avoids unwanted upgrades that could happen if pointing to master.
Also, right now Decidim only gives support to the latest released branch so it should not happen, but imagine we have already published 0.23, 0.23.1, and 0.24.0; but we need to publish 0.23.2. How we do that? by generating the 0.23.2 from the release/0.23-stable branch, and not merging to master, because master is already at 0.24. Then it doesn't makes much sense to have 0.23 and 0.23.1 in master but 0.23.2 in the stable branch.

Having been in the core/maintainers team during the last year, I think the cost of the workflow to keep master up to date it's not worth it
Here's an interesting alternative, GilabFlow: https://about.gitlab.com/blog/2020/03/05/what-is-gitlab-flow/ . Although I would go for @mrcasals ' proposal.