Symfony: Rename master branch to 5.2?

[GrahamCampbell]

Why?

1. The fact that master is 5.2 is currently expressed through a branch alias, which wouldn't needed at all if the branch was named in the conventional way.
2. It is clearer to contributors what branch they are sending PRs to, rather than them mistaking master for latest stable (5.1) when it is actually the next upcoming minor series (5.2).
3. The word "master" has undesirable connotations, and GitHub itself has announced (or leaked to the press, or whatever...) that it is looking to replace this term for the default branch of repos, anyway.

Possibly, as an interim, the master branch could be left around for a few months, and synced with 5.2 (to allow people to migrate if they have master or dev-master hard coded in various places).

EDIT: One problem with 5.x as a branch name is composer will install the 5.x branch with the version constraint 5.7.* even though there is no such version. This is why 5.2 is better, because it matches the current branch alias of master.

[colinodell]

I debated a similar change for league/commonmark as there are many advantages to this approach. I ultimately decided against it (and renamed master to latest) because you lose the ability to link to a branch name which never changes and is always the latest one: things like links to CHANGELOG.md or CONTRIBUTING.md would be "locked" to a certain minor version branch unless you continuously rename them. This may or may not be a concern here.

[derrabus]

you lose the ability to link to a branch name which never changes and is always the latest one

That would be my main concern with the suggested rename master ➡️ 5.2 as well. Apart from that, I don't have strong opinions on how that branch is named. We just should not perform such a renaming too often, for very much the same reasons. 😉

Since we have a next milestone on the issue tracker already, next might also be a good name for that branch.

[azjezz]

+1 for next as this would require the least amount of effort instead of renaming or/and changing the default branch after each minor release.

[GrahamCampbell]

Renaming to anything other than the version doesn't solve points 1 and 2. Only point 3.

[azjezz]

Also to note, this is not as easy as changing the default branch using GitHub UI. Symfony has some internal tools for releasing which would need to be updated.

[GrahamCampbell]

Could those internal tools not be updated to read the default branch information from GitHub?

[azjezz]

In that case, the tools would also need to change the default branch after a minor/major release for symfony/symfony and almost 60 other repositories ( components and bridges ), since the "5.2" branch would still exist, and "5.3" is now the default, GitHub will not update the targeted branches in the open PRs. meaning PR authors/maintainers will need to update the targeted branch.

this is quite a lot of work to do, I'm all for changing the name master, but having the default branch change at every release would put more work on the maintainer, and more time will be spent updating the internal tools.

[GrahamCampbell]

Changing the default branch can be done from the API can it not?

[azjezz]

Probably, but that still counts as time spent updating tools, and constantly updating PRs after releasing ( not sure if this can be done via the API 🤔 )

[nicolas-grekas]

I proposed using "next" a few days ago privately :)

Before doing the switch, we need a plan. "master" is referenced in CI scripts, composer.jsons, flex, etc.

We need to identify all those spots and make PRs to create a forward path. Sometimes (eg in flex AFAIK), we can completely remove any hardcoded branch name. In other places (eg. in composer.json), we might need to provide support for both "master" and "next" as a first step.

Help wanted.

[gmponos]

I proposed using "next" a few days ago privately :)

IMHO next can be a little bit blairy.. next is it 6.x or is it 5.x ?

[gmponos]

just thinking out loud.. composer or flex to point with a message branches that are "deprecated".. not sure if it is a good idea..

[wouterj]

@azjezz please note that Symfony already updates master branches each major release (while working on 4.4/5.0, the default branch is switched from "master" to 5.0, same will happen in 1.5 years for 5.4/6.0). So the core team already has tools to manage this :)

---

I agree with @GrahamCampbell that a version branch number is the most clear. While renaming "master" to another generic name solves any issues with the word "master", it doesn't fix any unclearity. As it's a lot of work to update the ecosystem to the new default name, I think this is the one and only moment to be able to fix all issues. Can we please consider using version branches?

For reference, using version branches is on its way to become an industry standard. To name a few popular projects in the Symfony ecosystem:

• https://github.com/twigphp/twig: 3.x, 2.x, 1.x
• https://github.com/friendsofsymfony/fosrestbundle: 3.x, 3.0, 2.7, ...
• https://github.com/laravel/framework/: 7.x, 6.x, 5.8, ...

In an ideal situation, GitHub should add a way to link to "the default branch" independently of its name (e.g. https://github.com/symfony/symfony/tree/_default will give you 5.2).

[nicolas-grekas]

:+1: on my side for 5.x

[GrahamCampbell]

https://github.com/laravel/framework/: 7.x, 6.x, 5.8, ...

Laravel only does that because it does major releases every 6 months, unlikely symfony which does minor releases every 6 months, so that comparison is not fair. The fair comparison is looking at Laravel 5's branch names, which are 5.0, 5.1, 5.2, 5.3...

[azjezz]

@wouterj the difference is that the default branch is always master, which doesn't change with a major release.

But I think 5.x can serve as a middle ground, where the default branch will only change every year and a half, so the issue of PRs targeting n.x instead of n+1.x will only happen when a new major is released unlike with n.i -> n.i+1 which introduced the issue every minor release.

Note: I think it's possible to update the PRs base branch using Github API ( https://developer.github.com/v3/pulls/#update-a-pull-request ).

[fabpot]

I think using the same strategy as Twig is a good idea. So, we would have a 5.x branch in place of the current master branch. When releasing a new minor version, we will create a new branch (5.2 would be the next) and keep 5.x for the next minor. Every two years, we would rename the "main" branch. In November 2021, 5.x would be renamed to 6.x.

If we agree, I will do the work as it means changing quite a few things here and there in internal tools. Also, I think I will maintain a master branch as an alias for 5.x for a few weeks to ease the transition for everyone (mostly for me probably :)).

[B-Galati]

What about completely removing the .x suffix? i.e. master would become 5.2 instead of 5.x (at the moment).
It would be explicit on which version we are working on.
It would not be needed to rename any branch, it would be needed to branch off 5.2 to create 5.3 at some point.

But there would be a problem that current PR would need to change the targeted branch every 6 months. That could also be a problem with .x notation but would happen less often.

[xabbuh]

But there would be a problem that current PR would need to change the targeted branch every 6 months. That could also be a problem with .x notation but would happen less often.

That's IMO a good reason not to use 5.2. The switch that needs to be done when development of a new major version starts is a switch we already need to do. It's just names changing here now (e.g. when the work on 4.4 started, new features had to be submitted to the 4.4 branch as master was for 5.0 back then).

[Ziggizag]

No! Word "master" has no "undesirable connotations". Only some crazy mob obsessed with racism in the worst possible sense is driving Orwell-like "newspeak" and stupid liberals follow as pointless sheep.

[GrahamCampbell]

Even if that were true, consider the term master as deprecated, for whatever reason... because it is. We need to decide on a replacement. There is no longer any reason to use master out of convention, because it soon will not be.

[Ziggizag]

It only "will not be" if the people blindly follow this nonsense.

[xabbuh]

You are free to continue to use master in your own repositories, but that's not to debate here.

[wouterj]

Let's not get this issue into political debates. As you can see in the description of this issue, only 1 of the 3 advantages of a versioned default branch is about suggesting that some people have negative feelings about "master" (which is btw something you can't deny, someone's feeling is always true).

Let's instead focus on the other 2 points of this issue. And given the +1's on Nicolas and Fabiens messages, I think the consesus is on using a versioned default branch.

---

_@GrahamCampbell I used Laravel's branch names as an argument to not use next/main/master, but a version instead. Didn't mean to say anything about the .x notation, so I didn't try to "mis-use" the example_

[Ziggizag]

@wouterj So - I have a negative feeling about making things upside-down only because somebody has "negative feelings". Anyway - political correctness is contemporary madness. I go away. Symfony is not my framework. I only use a few components. Good luck and beware next time somebody finds the word "Symfony" having negative connotations...

[atomatis]

Semantically, it's make more sens. "Master" word is realy weird when we learn git.
Especialy for non-english people.

[derrabus]

To be clear here, the word "master" is not an bad word by itself. What matters is the context that you're using it in. To be precise: It's the master/slave metaphor that is problematic.

You can still practice a skill until you master it. You can still graduate university as a master of science. And we will still be able to watch Star Wars movies where a Jedi master mentors their padawan.

But there's really no technical reason why the master branch has to be called master. It just happens to be the default that you get on a new git repository. But if you want to name that branch 1.x, main, next, purple-rabbit or awesome-things-happen-here instead, you're free to do so.

And talking about git, we in fact find the master/slave metaphor in disguise here. This is a good read on this topic: https://boleary.dev/blog/2020-06-10-i-was-wrong-about-git-master.html

[jrushlow]

I think this will be make headaches than it is worth. Especially for new contributors to Symfony. Aside from the technical aspects, the political undertones that motivated a lot of these types of changes across all software development communities - should not be the reasoning for such changes.

PHP internals is debating similar measures right now, and as stated there - its a premature step to a problem that doesn't exist (In terms of the context used within software community.) It also opens the flood gates to "Well I'm offended by this - that must be changed." & "But you changed it for that group of people, why not this group." I'm using that in a very broad sense, but the intent is to point out where does the boundary lay to negate the need to adopt such changes.

I would also argue that it is premature to begin renaming widely used industry terms on a per project basis. Wouldn't it be better to let things play out for a bit and see what terms(if any) are adopted so we can potentially coincide with then? I haven't seen any official word yet from any major organization (Github) as to "master" actually being changed to something else...

[wouterj]

For the sake of scoping the debate, let's imagine the default branch has been named "🌳" for years already.

_If I submit a PR for "🌳", which version will it be released in?_
No idea (hint: 5.2)

_Is the "🌳" from today compatible with the "🌳" I downloaded 12 months ago?_
No idea (hint: yes, but if you said "13 months ago" the answer would be no)

_Our composer.json says "symfony/symfony": "dev-🌳", which version of the docs do I need to read?_
It depends... (hint: try to discover when composer update was executed, then visit https://symfony.com/releases and check which version was in development back then)

It's not very important to discuss the current name, it's important to discuss if another name has more advantages. I think it clearly has, as all three questions will be answered without knowing anything about Symfony.

[Ziggizag]

@wouterj
Does it matter?

If you want to commit to specific version - you are about to PR to specific branch.

If you want to commit to the "master" it means - you want your PR to be included in the most recent version not "history" version. If your PR passes through tests and peer review - you are fine. You do not need to worry is it v.5.x or v.6.x

[Saibamen]

WTF...

[ro0NL]

i think we should keep a latest branch alias, inferred from what semver tells us is the latest version. If only for practical reasons.

then, all real branches being real versions (x.y) makes sense to me. The .x suffix somewhat bugs me now, as 5.x is just 5 also (which could be another branch alias :))

is there any reason to not be explicit basically?

[Ziggizag]

master or latest - just the same. The change would be just an unnecessary problem for less oriented users. For myself this is a hyped issue driven by silly political sentiment and adversary culture.

[ro0NL]

if anything, it made me realize i have a slight preference for latest over master :sweat_smile: and i use master instead of latest (in the context of versioning) with git only :sweat_smile: compared to any api i wrote.

[Ziggizag]

I would say - I can understand your individual choice - no problemo, but have a look - a few comments above a guy is complaining about "latest" in case of Docker.

[deflock]

To me latest sounds like production-ready.
And 5.x sounds like something abondoned, unsupported anymore or 5.0-prealpha.
IMO

[dunglas]

GitHub and Chrome (and probably other projects) are planning to rename master in main: https://twitter.com/natfriedman/status/1271253144442253312. When GitHub will change the default name for all new projects, it will be the new de facto standard and tools will update quickly.

I suggest to switch to main so it will be as easy as today for new contributors (because main will be the new standard) and they will be able to use all the tools they are familiar with (GitHub Desktop, the VS code extension etc).

[zmitic]

Absolutely... I am sure that poverty, discrimination and violence against black people will be solved with this change.

And people on protests right now will surely feel better because of this.

Cops will think twice because PHP removed blacklist from code and PHPUnit changed config files; we are really changing the world for the better.

---

Why stop here; why not put thoughts&prayers in the code; we all know they are effective.

But please, don't suggest something tangible like putting a donation link on your site.

And never ask black people what they think; you know better. You know that master->main is super important, you know that phpunit.xml is all that victims really care about.

/s

This message is not for OP but for people who think they help, but in fact, do the opposite.

They don't do it intentionally; they want to help, they think they helped and then leave at that. It will always be in their minds "I did what I could".

And none of them asked black people how to actually help. Given how much this nonsense is spreading, I have a feeling that every attention-whore will try to force PC in every possible topic.

Just so they can feel better for doing nothing useful.

---

This is message I posted on reddit, you can follow entire thread here.

There are more arguments there why this change will actually bring more harm than good; follow the video there with real case. But watch it carefully; it is made by real scientist, person trained in critical thinking.

---

Feel free to downvote me if you really think I am not right. But you know I am.

[jrushlow]

This is an excerpt from a PHP Internals mailing list on the same type of discussion (From another user). I think regardless of what we do here in symfony - it's a point we should take into consideration. For context, we're discussing changing the term blacklist in opcache ini files and else where within the code base.

Hello everyone,

I would like everyone to slow down a bit and give a think about this:

English is not the primary language for the vast majority of people. are
a thing and a lot of people, actually, work with PHP that either does not
know English at all or, know the basics and rarely have the English skills
to a level that allows them to easily understand subtleties of things.
What you need to consider, that some alternatives that are being talked
about, may not have a translation. Like at all. Here's a case and point for
the Russian language - there is no alternative, as far as I can tell, for a
"blacklist" that has the meaning blacklist or exclude list can be
translated. The only Russian phrase that I know of (and I tried searching
for alternatives) is a literal translation of the phrase "black list".
Anything I could think of just didn't fit - there is just no other word
that describes an "exclude list" - it translates literally to "black list"
anyway.
Same goes for the Latvian language - the only word we have for it is a
literal translation and nothing else.

And I suspect, it might be the case for many other languages too for a
simple reason - the term came from English first and got adopted one way or
the other into the language because there was no counterpart for it in it.

On the other hand, Russian has a great translation for the "master/slave"
combo - ведущий/ведомый that has 0 association with anything slavery
related. But the literal translation to English is "master/slave", and it
does not translate correctly to "Primary/Secondary" or other alternatives
I've seen around, because it looses all meaning that Russian words describe
for the technical implications of how things work in mechanics, engines and
so on. it's also actually used in aviation too between Commander and Second
Officer. Closest I can translate it is "Leading / One who is led by the
leading".

Just my 0.02$ as food for thought, because PHP is not a regional project.
This is a global project and it's userbase overall, probably, is not
primarily English speakers. A lot of us just revolve around in English
speaking tech bubble, because it is the international language and it is
easiest for everyone who is involved in OSS projects and international
companies. But I'm not, personally, an English speaker - English is my 3rd
language.
I also live in Russian tech space and it is pretty common to have
developers who do not know English to a level of speaking and/or reading
and relly on documentation translations and those established
industry-standard terms that they know and/or use google translate.

P.S. I just run "exclude list" through google translate into Russian and
Latvian - let's just say that translations were confusing at best because I
can't judge how bad they would be for a person who does not know English
well or at all.

[Ziggizag]

@jrushlow

We have neither Polish equivalent of "blacklist / whitelist" nor "master/slave". And for your info:

Polish, Russian, Chechs, Solvaks etc. - we are all "SLAVES". And... can you imagine - we do not show massive hysteria due to such a lexical abuse!

So - for myself all these Anglosaxon madness is very annoying.

[deflock]

That's sad these renames happen after some political events in just one country of the world.
Let's rename everything after something happens in China, Thailand, Iran, Saudi Arabia, Columbia, Madagascar, Antarctica.
When I started learn git after mercurial and saw that default branch is named master I thought "What the hell does it mean???"
But I agreed with this ridiculous name as a convention. And now these events... and everyone is concerned of renaming everything. Why just now and not a year ago?
I suggest postpone this change to the next year and then decide if this rename matters

[derrabus]

Can you please elaborate how a renamed master branch will affect you or the projects you are working with?

[Ziggizag]

@derrabus

I would rather ask - what about all these people, who refer with "dev-master" in their composer.json. Any idea? Do you like the mess of invalidating tenths of thousands composer structures worldwide for such a "progressive" move?

[gmponos]

Besides the political reasons I would like to see symfony changing the branches for the reason no2 that Graham initially mentioned...

So someone pointing to dev-master of a package is like having a deathstar in his composer

[Ziggizag]

@gmponos While true in general terms - it's often practical as many projects are bound to rather immutable facade and are focused only on code optimization and security.

[GrahamCampbell]

I really did not intend for point 3 to be a point of discussion here. It is not relevant for choosing a new name, but it was a motivating factor, along with the other 2, for wanting a better name. Discussion of point 3 is not for here.

[azjezz]

@Ziggizag as far as i can see, dev-master wasn't your point, but rather point 3 made by @GrahamCampbell

Anyway, as @fabpot noted, the master branch will still be kept for few weeks before deleting. and I'm pretty sure a month or so i more than enough for you to change dev-master to dev-5.x in your composer file.

[Ziggizag]

@GrahamCampbell So again - can you provide a SWAT analysis on the subject? What are these extraordinary advantages of having "v.5.x" or "v.6.x" against PR to particular branch directly vs. PR to "master" in case of such an intend?

[derrabus]

what about all these people, who refer with "dev-master" in their composer.json.

All right. As @gmponos pointed out, pointing to dev-master in your composer.json is not a good idea in general. But it might make sense in CI builds for instance.

So, if we rename the master branch, we need to make sure that the dev-master alias continues to work for a certain amount of time.

Anything else?

[Ziggizag]

@azjezz Sure - in case you control your composer.json... But in case you've just maintain an app and update composer for security - the abrupt change might be a problem for maintainer.

[azjezz]

Then i guess few weeks are enough to get hold of the maintainer and tell them to update it otherwise your app would just stop working.

Unless this is a mysterious maintainer that only appears when a security issue happens.

[wouterj]

dev-master is as unstable as it gets. If you have a maintained app without active developers, it's an even more scary thing to have dev-master in there. Please please please use an LTS version in that case.

Anyway, I think all arguments are clear and there is not much point in repeating the arguments over and over again. The votes are also given and more importantly, the 2 persons that are most affected by this change commented with an approval. For the other 1000+ contributors - you'll probably need to do git checkout 5.x over some weeks. For the other millions of users - no change needed unless you're using bleeding-edge Symfony (and in that case, I take my hats of for your bravery!)

[Ziggizag]

@wouterj OK - let it go. I am a conservative animal, but it seems the tide is high. Let's see where it goes.

[GrahamCampbell]

(and in that case, I take my hats of for your bravery!)

Yeh, things might break, like the branch name changing. :trollface:

[jrushlow]

The votes are also given and more importantly, the 2 persons that are most affected by this change commented with an approval. For the other 1000+ contributors - you'll probably need to do git checkout 5.x over some weeks.

I'm sad to interpret that as essentially - 2 people have a say, the rest can voice there opinion but it doesn't matter... And i think it is worth reiterating again - this affects everyone, not just 2 people who are "most affected"...

[wouterj]

2 people have a say, the rest can voice there opinion but it doesn't matter...

https://symfony.com/doc/current/contributing/code/core_team.html

But really, that's even more unrelated to this issue than the complete political discussion about point (3)

[GrahamCampbell]

the rest can voice there opinion but it doesn't matter.

Yeh, basically. I really opened this for consideration only by the symfony core team, who spend literally months of their lives working on the codebase. Of course what they think matters more than anyone else! Of course everyone can have input, but ultimately, it's not up to a public vote.

[derrabus]

this affects everyone

All right, how does it affect you?

[GrahamCampbell]

I think this issue is getting somewhat off topic, and it has pretty much been decided that master will be renamed to 5.x. I don't see what else there is to discuss?

[Ziggizag]

Roma locuta - causa finita.

[jrushlow]

This is a community, not a dictatorship.. To infer that only the opinions of the core maintainers matter is just wow...

[xabbuh]

@jrushlow How are you affected by this change?

[GrahamCampbell]

Again, this is off-topic. Please do not comment if you have nothing to add to the discussion of the OP.

[jrushlow]

This will effect my workflow when I'm contributing to Symfony and it's related packages.. It also affects automation for testing in local / CI environments.. A lot of projects in PHP (including PHP itself) are debating changing industry terms right now. That's fine.. Debate it, talk about it, but put some thought into it and do not make an overnight decision about it. What will happen when every project chooses their own alternate term for the "master" branch? There should be consistency. And that is not just a hypothetical..

IMO this "movement" across software development to change industry terms is of a political nature. I don't feel changes in our industry should be motivated by anything political... It opens the flood gates to unknowns..

Even more so, as a contributor to Symfony, user of Symfony packages, and having a profession that deals with Symfony - I'm very taken back that "my opinion doesn't matter." How is that promoting a welcoming environment here in Symfony?

[Ziggizag]

@jrushlow You know - "gender is just a social construct and there is no essential differences between genders". This is a new dogma, but for whatever reason, this "not essential" aspect of life has become a critically important issue for LGBTQ identity politics...

So, we used to live with master/slave for decades and nobody even linked these industry terms with anything political until it was politicized by radical left-identitarian mob called #BLM. And suddenly we are in urgency to switch terms overnight as they were proven not appropriate - regardless 5 consecutive Symfony versions were developed using "master" branch convention and nobody ever complained...

Well - we are drawn into abyss with good intentions. Anyway - I am sure one day word "Symfony" will become suspicious. Symfony is white men development. It is the paramount of the "culture of whiteness". How could it be? Why not "Kalimba" or "Obokano"??? Symfony will have to be regarded as offensive expression of white privilege and must be abandoned in favor of some less racially stigmatized name.

Good night!

[lsmith77]

Now you are starting to mix a lot of topics into this thread. Why do you feel the need to bring them up? To me this illustrates that you are simply using this thread to voice your disapproval about a general development of the world in general and not discussing the merits of the proposal. But if we go this direction, why do you think it is that an industry that was originally mostly comprised of women is now mostly comprised of men? Because women were pushed out. And why is it that so many other groups are under represented? Because they also either get pushed out (Alan Turning) or because they were never let in. But the “open” in “open source” doesn’t just stand for access to source but also for community.

Now in this thread “community” was also invoked as to mean that there should be a public vote of sorts. I also think that the reason why Symfony has been so successful is that it is not just the personal needs of a core team that is taken into account in the decision making process. But you can see very well that the change was discussed and risks were analyzed. The approach that is now planned to be taken has been tested and implemented already inside Twig and it went through without much issues at all. So it is not a rushed decision at all.

[javiereguiluz]

@jrushlow about this:

I'm very taken back that "my opinion doesn't matter." How is that promoting a welcoming environment here in Symfony?

I'm sorry if some comments made you think that. Of course we listen to all opinions. Symfony is not an echo chamber. Sometimes we've changed our mind or haven't done something because of the community opinions.

The Core Team is used to vote on technical proposals (we hear all opinions, but ultimately, only the Core Team votes are considered for the final decision). This is similar to most comparable Open Source projects.

[alcaeus]

On-topic part: I'm in favour of this change, and I don't think that there will be a lasting negative impact from this change to contributors, maintainers, or users of this library. There may be short-term disruptions, but I think these have been considered and addressed appropriately (namely, keeping a master branch as fallback for some time).

For what it's worth, I don't think that this change will do anything to significantly make a change in the grand scheme of things or help ending the oppression of people of any kind. However, that doesn't mean that we should not make this change.

One point that hasn't been mentioned is that many PRs are sent to master "by default", as that is 1) the default branch of the repository, and 2) is what people know. However, many PRs should be sent to support branches, and not having a "master" branch to fall back on will require people to think about what version they need to target with their PR. Could this result in a lower number of contributions? Sure, but only time will tell. Could this mean less work for maintainers, as they won't have to re-target PRs to different branches? Sure, but only time will tell.

---

(note: no technical or sensible arguments related to this change follow. Feel free to disregard if you're only coming to discuss technical issues).

Now for some off-topic stuff because I've read too much nonsense here. Note that I'm quoting @Ziggizag here, but this goes for the benefit of everyone that wants to make the same or similar arguments.

So, we used to live with master/slave for decades [...] 5 consecutive Symfony versions were developed using "master" branch convention and nobody ever complained

We also used to refer people of colour by a different word which we now consider quite abusive. Throughout history, we used to buy, sell, and kill people because of where they were from, or because we believed we were superior to them. We took whatever we wanted from other racial groups, minorities, and even native populations, and in some cases we continue to do so. Just like the US has a history of slavery, Europe has a sad history of serfdom that was similar in nature. Yet we realised that this wasn't a way to go, and we made changes to no longer have this happening (at least not as obvious). Going with the "we used to do this" argument is a fallacy, as it implies that we should not change our ways, ever.

I'd throughly disappointed by the arguments some people here make against a change like this. You'd think that if this change was indeed as controversial as some make it out to be, there would be a very large majority of people arguing against it. Yet, we have a handful of people arguing back and forth, setting up straw man after straw man to keep the discussion going and refuse to even consider alternative opinions. I'm not saying we shouldn't hear opposing arguments, but when these arguments are not brought in good faith, there comes a point where we say "alright, that's enough" and move on.

Polish, Russian, Chechs, Solvaks etc. - we are all "SLAVES"

First of all, the word you're looking for is "Slavs", not "Slaves". I'm making this point because I didn't know where the word came from, so I took the time to educate myself. So, to quote wikipedia (excerpts from https://en.wikipedia.org/wiki/Slavs_(ethnonym), which I encourage you to read):

The Slavic autonym *Slověninъ is usually considered a derivation from slovo "word", originally denoting "people who speak (the same language)", i. e. people who understand each other [...]

Later on:

The English term slave derives from the ethnonym Slav. In medieval wars many Slavs were captured and enslaved, which led to the word slav becoming synonym to "enslaved person".

I'll leave further conclusions to everyone reading this, especially the fact-twisting that you've done in order to try and make a (in my opinion) ridiculous point.

---

With all that said, I'd like everyone who is clutching their pearls right now going "but muh freedoms" to think about how other people feel in this or similar situations. When you argue that "blacklist" and "whitelist" should not be changed because they have nothing to do with skin color, yet clearly associate "black" with "being denied" and "white" with "being allowed". When you say that you'll be negatively affected, are you really going to suffer from a naming change in a repository, or are you just overwhelmed with what's going on in the world at large and need time to re-adjust? If so, it's perfectly fine to take a step back, look at the line you've drawn in the sand, and checking just how far away from everyone else that line is.

[javiereguiluz]

Thank you all for the discussion. Just a reminder: let's keep the discussion focused on the technical side:

• Should we rename master branch or not?
• If we do, should we rename it to latest, next, develop, 5.x, other?

For related, but not technical, discussions, please use Symfony Slack at https://symfony.com/slack Thanks!

[gmponos]

Thank you all for the discussion. Just a reminder: let's keep the discussion focused on the technical side:

🙏

I vote for 5.x

[alherd-by]

Hello @GrahamCampbell

Possibly, as an interim, the master branch could be left around for a few months, and synced with 5.2 (to allow people to migrate if they have master or dev-master hard coded in various places).

Why do I need migrate to anything? You didn't provide sufficient reasons to do so.

The word "master" has undesirable connotations

It is not the reason to introduce massive BC-break across ecosystem(source-code, documentation, guides etc). It is ignorance(read etymology) and virtue signalling.

[fancyweb]

I'm in favor of renaming current master to 5.x.

[atomatis]

latest or 5.x for me.

[javiereguiluz]

I checked the Symfony Docs to estimate the impact of this change. We would have to update a couple of occurrences in these three articles:

• contributing/documentation/overview.rst
• setup/_update_all_packages.rst.inc
• setup/unstable_versions.rst

And we also have several links in other articles that point to github.com/ ... / master / ... but we can update those with a "Search & Replace".

So, it looks doable witout much effort.

[alherd-by]

@javiereguiluz You are missing the point or deliberately misleading conversation. Why do we need to introduce change for the sake of change?

[javiereguiluz]

@alherd-by in my previous comment I asked two questions. The first one is _"should we rename or not"_ which is what you say we should be asking first. About the reasons, @GrahamCampbell gave three reasons in the description of this issue.

[gmponos]

If you want the view of a contributor (meaning my view) recently I submitted one-two PRs and I got confused if master was 6.x or 5.x. Personally I wanted to target 6.x with those changes..

IMHO this will make it clear.. which is the point no2 initially mentioned.

[derrabus]

@alherd-by How will this change affect you personally or the projects you're working with?

[tavy315]

Perhaps GitHub will implement a "default" alias to master/main/latest/next branch, so best choice would be 5.x.

[faso-dev]

i propose to use current or next

[wouterj]

@alherd-by in all honestly, I think your comment should be ignored. It has been mentioned countless times already that point (3) is not of dicussion in this issue and the focus should be on point (1) and (2). If you keep only mentioning point (3) for the sake of discussion, it has no place in this GitHub issue and you should try to find another medium to source your opinion.

---

👍 for 5.x. I think it's a good middle between the most clear 5.2 option and not having to update the PR branches every 6 months (given the 1.5 year update of PR branch is also needed in the current release proces, as 5.4 will be the default branch for the 6 months leading up to 5.4/6.0 being released).

[arkste]

i'm totally for this change, because of 1 & 2, but:

renaming master to a minor specific branch like 5.2 (especially since there's a new minor release every six months) requires to update the branch more frequently (+ everything around it).

it will be less common, but the same will happen if you rename the branch to 5.x, not only the branch itself has to be updated, but also everything around it once the development on 6.x starts.

it might work for twig, but afaik twig doesn't have the same release cycle as symfony and doesn't generate that much work as it would with symfony (just a guess).

i (as a developer) wont have to do the work, so I'm not really affected directly, but i would save the core/docs team from doing such a tedious task every time a new release is created.

therefore, i would vote against a version specific default branch only (i'm still for the change, please continue reading).

to resolve 1: why not rename master to a major version specific branch 5.x and then create a latest branch alias which will always point to the recent version? basically turning the current solution around? wouldn't this be the "best of two worlds"? working with version specific branches has it benefits (especially since symfony already has them everywhere else) and because a branch alias points to the most recent version, you won't have to update stuff (docs, ci scripts, etc) around it that often.

tldr: i would vote for a major specific default branch 5.x with a latest / next branch alias pointing to it.

[wouterj]

To add some numbers:

• GitHub has indexed 95K composer.json files with a requirement on symfony/symfony: ref
• Of these, only 33 use dev-master: ref
• Only one of the 33 is updated after 2018: https://github.com/Aurelien-bnd/Test-Spyrit-PHP

So I think we can conclude that we already educate people to not use dev-master and that there aren't going to be a lot of projects who are affected by this.

[GrahamCampbell]

One problem with 5.x as a branch name is composer will install the 5.x branch with the version constraint 5.7.* even though there is no such version. This is why 5.2 is better, because it matches the current branch alias of master.

[tavy315]

I guess documentation has to suffer same changes?
https://symfony.com/doc/current/components/index.html refers to 5.1
https://symfony.com/doc/master/components/index.html refers to 5.2

[arkste]

One problem with 5.x as a branch name is composer will install the 5.x branch with the version constraint 5.7.* even though there is no such version. This is why 5.2 is better, because it matches the current branch alias of master.

is there any way you could mark 5.x as dev and avoid it getting pulled using composer's minimum-stability: stable?

5.2 as a branch name implies (at least to me) that the code in this branch is in a stable and already released state. without knowing anything about the current version and release cycle this would be confusing as well, you wouldn't solve 2.) imho.

[derrabus]

is there any way you could mark 5.x as dev and avoid it getting pulled using composer's minimum-stability: stable?

The head of a branch has always dev stability. Only tagged releases can be more stable.

[derrabus]

So I think we can conclude that we already educate people to not use dev-master

Yes, but we also educate people not to use the monorepo as a dependency. We would have to look into references to the individual components as well. I would expect similar results, though.

[wouterj]

Yes, but we also educate people not to use the monorepo as a dependency. We would have to look into references to the individual components as well. I would expect similar results, though.

I know. Unfortunately, that can't be done using the GitHub search. "symfony dev-master" only matches symfony": "dev-master" - so ending up with monorepo again. "symfony" "dev-master" matches any occurence of both words in the file, which is rather pointless.

Anyway the "no dev-master" recommendation existed many years before the "no monorepo" recommendation. So I expect the results to be lower if anything.

[jrushlow]

It has been mentioned countless times already that point (3) is not of dicussion in this issue and....

@wouterj - you cant say something is not of discussion when it was clearly brought up as part of the reason for this suggested change by the OP. I get that we should not be using Github issues to voice political opinions (I'm with you 100% there), but that is exactly what was done when this issue was created..

[Pierstoval]

Twig was proposed as an example of success to this, a proposal is made for Symfony, it can be done, it clarifies things a lot.

Now the discussion goes on, almost a hundred of comments, all the relevant thing I can see is this:

So, it looks doable without much effort.

Enough to make a decision IMO.

About the people that refer to "dev-master", they seem really marginal, and it's not a really good practice anyway (unless for development or to anticipate errors, which is not really major either), there are hundreds of resources to know that. I tend to think they're even fewer than the number of people that have problems when migrating from a minor version to another minor.

Changing the default branch can be a motivator for education too.

[ro0NL]

btw, if we aim for semantical value, and a naming change is gonna happen either way; im not sure about main either :) all versions are about the main thing. "latest" IMHO conveys better meaning, whereas "main" sounds like a good default for project repos in general, not a semantic versioning scheme per se.

IMHO

5
  5.2
    5.2.N
4

comes closest to semver, going from aliases, to branches, to tags. Meaning i would even throw the v prefix up for debate :smiling_imp:

however, if the gain of sticking with "github's maybe future default" is massive, then ok. But it feels wrong not being able to pick a default that fits best, on a per repo basis.

edit: oh well, checking out "main", gives you the latest main thing. Makes sense as well :shrug:

[kor3k]

"master" hAs uNdESiRaBle cOnNoTaTiOns

no it doesn't. only true racists see racism behind everything.
me for example never thought about "master branch" in slavery context, until some libtards came up with that BS recently. and i think it's completely absurd and pathetic.

but point 1. and 2. are valid IMHO.

[kor3k]

@GrahamCampbell please consider setting up a petition and urge the government of the country Montenegro to rename their country to something else. because, you know, it contains the word "negro" in it, which also hAs uNdESiRaBle cOnNoTaTiOns.

---

This is the way the world ends. Not with a bang, but a whimper.

[javiereguiluz]

GitHub has published this -> https://github.com/github/renaming

Highlights:

• main is the new default name chosen to replace master
• GitHub officially recommends to NOT CHANGE your default branch yet and wait a few months to use a tool they are developing to make the process seamless (otherwise, lots of things and links will break)

[fabpot]

WIP, the 5.x has just been created and the master branch will be removed in a few weeks. Thanks all for the discussion.