Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump flex to v2, composer >= 2.1, php >= 8.0 #833

Merged
merged 1 commit into from
Nov 28, 2021
Merged

Bump flex to v2, composer >= 2.1, php >= 8.0 #833

merged 1 commit into from
Nov 28, 2021

Conversation

nicolas-grekas
Copy link
Member

Let's drop the legacy since Symfony 6.0 will require composer >= 2.1 anyway.

@nicolas-grekas nicolas-grekas force-pushed the v2 branch 6 times, most recently from ed0d0cb to 783961b Compare November 22, 2021 18:19
@Nyholm
Copy link
Member

Nyholm commented Nov 22, 2021

Except for "remove legacy code", is there reason to release a new major version?

@weaverryan
Copy link
Member

Should the branch be called 2.x?

@nicolas-grekas
Copy link
Member Author

nicolas-grekas commented Nov 22, 2021

Since Symfony 6 is already requiring composer >= 2.1, I think it's just the right timing to fade out this legacy code yes. Eg I don't want to maintain the CurlDownloader anylonger, and keeping it alive in maintained version is a 💣 waiting to explode on my free time :) The earlier the better.

@nicolas-grekas
Copy link
Member Author

Should the branch be called 2.x?

then we'd drop main? could be

@weaverryan
Copy link
Member

then we'd drop main? could be

That's what I was thinking. The main branch feels more and more of an "odd ball" to me compared to 1.x, 2.x branches anyways.

@nicolas-grekas
Copy link
Member Author

main dropped, welcome 2.x :)

@GromNaN
Copy link
Member

GromNaN commented Nov 22, 2021

How long do you think the branch 1.x should be supported? PHP 7.4 EOL is in 1 year, and Symfony 5.4 EOL (with PHP 7.2 support) is in 4 years.

If we want to push adoption in order to not maintain legacy code, I think PHP requirements should stay to 7.4 max for now. PHP 8 has several breaking changes that make some projects hard to update.

if ($populateRepoCacheDir && isset(self::$repoReadingCommands[$command]) && ('install' !== $command || (file_exists($composerFile = Factory::getComposerFile()) && !file_exists(substr($composerFile, 0, -4).'lock')))) {
$this->populateRepoCacheDir();
}

$app->add(new Command\RequireCommand($resolver, \Closure::fromCallable([$this, 'updateComposerLock'])));
$app->add(new Command\UpdateCommand($resolver));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should those registration be changed to use the CommandProvider of the Composer 1.1+ plugin API instead of relying on the backtrace hack to access the Application ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just had a look and I think there are little benefits in doing so. Limiting merge conflicts with 1.x looks more important to me right now.

@nicolas-grekas
Copy link
Member Author

How long do you think the branch 1.x should be supported? PHP 7.4 EOL is in 1 year, and Symfony 5.4 EOL (with PHP 7.2 support) is in 4 years.

With 5.4 the latest, earlier if possible. Stats might help decide.
We should continue merging new features in 1.x of course, since flex is the way to push better DX to our ecosystem.

If we want to push adoption in order to not maintain legacy code, I think PHP requirements should stay to 7.4 max for now. PHP 8 has several breaking changes that make some projects hard to update.

Symfony 6 is already for PHP8, there is no point in having flex use different versions than both 5.4 and 6.0 to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants