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

Remove EOL PHP 5.4 from .travis.yml and composer.json - Fixes #5862 #5863

Merged
merged 3 commits into from
Jun 8, 2016

Conversation

tPl0ch
Copy link
Contributor

@tPl0ch tPl0ch commented Jun 8, 2016

See #5862 for more info

@tPl0ch tPl0ch changed the title Remove EOL PHP 5.4 from .travis.yml - Fixes #5862 Remove EOL PHP 5.4 from .travis.yml and composer.json - Fixes #5862 Jun 8, 2016
@@ -14,7 +14,7 @@
],
"minimum-stability": "dev",
"require": {
"php": ">=5.4",
"php": ">=5.5",
Copy link
Member

Choose a reason for hiding this comment

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

We should change this to ^5.5 || ^7.0

@Ocramius Ocramius added this to the 2.6.0 milestone Jun 8, 2016
@Ocramius Ocramius self-assigned this Jun 8, 2016
@tPl0ch
Copy link
Contributor Author

tPl0ch commented Jun 8, 2016

@Ocramius Done

@soullivaneuh
Copy link

soullivaneuh commented Jun 8, 2016

@Ocramius 👍 for version support dropping, but this should be done on a new major IMHO.

Dropping PHP support is BC break for developers using this bundle under the dropped version.

@Ocramius
Copy link
Member

Ocramius commented Jun 8, 2016

Dropping PHP support is BC break

This has been discussed ad-nauseam. Dependency requirement bumps (any dependency) are not BC breaks. This will not break running systems, and systems running 5.4 will simply reject Doctrine ORM 2.6.x when running composer update, falling back to 2.5.x.

We've also done this previously in the 2.4 -> 2.5 upgrade.

should be done on a new major IMHO.

Done it multiple times in Doctrine, in Zendframework and in other libraries: not a problem, and also not perceived as a problem by consumers. Dropping support for un-maintained PHP versions is also the most responsible thing to do from a security perspective.

@Ocramius
Copy link
Member

Ocramius commented Jun 8, 2016

Failing tests are related to #5854 and #5856

@Ocramius Ocramius merged commit 9b90226 into doctrine:master Jun 8, 2016
@Ocramius
Copy link
Member

Ocramius commented Jun 8, 2016

Thanks, @tPl0ch!

@soullivaneuh
Copy link

@Ocramius I understand, you are technically right.

Symfony does not follows this way, so I think it's a matter of choices...

Thanks for your explanation anyway. 👍

@Ocramius
Copy link
Member

Ocramius commented Jun 8, 2016

Symfony does not follows this way, so I think it's a matter of choices...

Top of the page says doctrine/, in fact, not symfony/ :-P
Also, we don't have the throughput capabilities of Symfony: less versions to maintain is just less headaches.

@soullivaneuh
Copy link

Top of the page says doctrine/, in fact, not symfony/ :-P

Yeas I know, this is was I said:

so I think it's a matter of choices

😉

Also, we don't have the throughput capabilities of Symfony: less versions to maintain is just less headaches.

I totally understand you for this point. 👍 Having same issue for Sonata projects.

@tPl0ch
Copy link
Contributor Author

tPl0ch commented Jun 8, 2016

@soullivaneuh In addition to @Ocramius points I also believe that libraries can be a vital driver for new PHP version adoptions this way. When an EOL is reached it's time to increase the pressure on consumers, and libraries like doctrine can instrument a big leverage here.

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

Successfully merging this pull request may close these issues.

None yet

3 participants