Closed jrfnl closed 1 year ago
I'm in favor of moving away from master
.
I'd say, for now, lets just move to main
ASAP (since we're making other soft-breaking changes to our dev environment anyway).
We can always move to something more elaborate when needed.
My 2️⃣🪙
Places that need editing for this rename:
https://github.com/PHPCSStandards/composer-installer/blob/5227b24999e01c09a0f23b9bf53c8ee13eec4d05/.github/ISSUE_TEMPLATE/bug_report.md?plain=1#L52 https://github.com/PHPCSStandards/composer-installer/blob/8ab9bb58b13045f5e64ebe9ba13d8701c416dcf3/.github/workflows/integrationtest.yml#L8 https://github.com/PHPCSStandards/composer-installer/blob/8ab9bb58b13045f5e64ebe9ba13d8701c416dcf3/.github/workflows/quicktest.yml#L8 https://github.com/PHPCSStandards/composer-installer/blob/8ab9bb58b13045f5e64ebe9ba13d8701c416dcf3/CONTRIBUTING.md?plain=1#L10 https://github.com/PHPCSStandards/composer-installer/blob/8ab9bb58b13045f5e64ebe9ba13d8701c416dcf3/CONTRIBUTING.md?plain=1#L134
@jrfnl Do we want to make this change as well for the v1 release?
If we make this change, then, yes, the 1.0 release would be a good time to do so.
I suggest doing it just before the 1.0 release.
That way, if there are people who use dev-master
, their workflow won't be broken without a notification (i.e. a mention in the release notes for the 1.0 release).
Another vote +1 for main
branch just before the 1.0 release.
Resolved by #201
That way, if there are people who use dev-master, their workflow won't be broken without a notification
Eh... consider me one of those people whose workflow was broken without notification. I thought you might be able to prevent breakage by adding a branch alias, but it seems like that's not possible: https://github.com/composer/composer/issues/11301
@danepowell Out of curiosity: why were you using the master
branch instead of a tagged release ?
We needed https://github.com/PHPCSStandards/composer-installer/pull/167 which was only in master
at the time.
@danepowell Interesting. That bug was never reported by anyone, but clearly people (you) did run into it. Thanks for letting me know.
The good news is, of course, that the bug fix is included in the 1.0.0 release, so you should be able to switch back to versioned updates now.
Hey 👋🏼
A project I work on has also just been caught out by this change
One of the packages we use pushed a fix yesterday changing from dev-master
to dev-main
but they've not yet been able to tag and publish a new release yet...
Whilst we work to resolve these issues on our project, we'll create upstream updates for the packages we use and hoping they're maintained and can push new releases soon as this will be tricky for packages that are not so well maintained
A quick GitHub search shows 14 of the first 50 search results (3481 total results) use dev-master
Unsure of a workable solution, though a solution from Composer would be ideal, I've subscribed to https://github.com/composer/composer/issues/11301 and will be interested in replies there...
Edit: Whilst we run our build script using the --no-dev
flag to install packages as part of our deployment process Composer still requires that require-dev
packages satisfy version requirements as per this message displayed:
-no-dev
does not mean require-dev
is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems."@jrfnl Should we create a branch keep the master
from main
master
branch which I accidentally creatyed from main
for now until things are further resolved?
Apparently I just created one (I was fiddling around with the UI and apparent filling something in already creates the branch)
@Potherca I don't think so. Yes, the change is inconvenient for people, however:
dev-master
(or dev-main
) anyway.dev-master
/dev-main
.It's also a one-time only change (at least that's the intention) and we executed it in the most considerate way possible:
I'd recommend for people who choose to use dev-
branches of repos to watch the repo or, at the very least, watch release notifications of those repos, but that's not our responsibility.
The official suggestion from composer in https://github.com/composer/composer/issues/11301 is that you should create a 1.x branch alias for main and projects should use that instead of dev-master or dev-main. That means not keeping a duplicate branch.
Should we ~create a branch
master
frommain
~keep themaster
branch which I accidentally creatyed frommain
for now until things are further resolved?Apparently I just created one (I was fiddling around with the UI and apparent filling something in already creates the branch)
Oh, this could be why I've not encounted this previously.
GitHub redirects renamed branches, but only if they were renamed
In a way a "bit late to the party", but should the default branch be renamed away from
master
?And if so, what would be the preferred new name ?
Some options:
main
. For a "one branch" repo, that would be an obvious choice.stable
branch as a release branch and have adevelop
branch as the default PR branch. For a new releasedevelop
would then be merged intostable
.Opinions ?