search

Respect / Validation

The most awesome validation engine ever created for PHP
https://respect-validation.readthedocs.io
MIT License
5.8k stars 774 forks source link

Drop php 5.3 support #364

Closed malukenho closed 9 years ago

malukenho commented 9 years ago

It's not encouraged anymore.

henriquemoody commented 9 years ago

:+1:

augustohp commented 9 years ago

:-1:

Although it is not encouraged, what we will gain of that? We could use PHP >= 5.4 features for our benefit but that would not change our current game would it?

Although I support using only stable versions of PHP, I don't think it is in our role as a package to enforce it. Specially for the 1.0 version.

On 2.0 with the changes proposed by @henriquemoody if am a :+1: but for 1.0 we should at least respect our current constraints.

alganet commented 9 years ago

@augustohp We gain a free out-of-jail BC card in the future:

If we stick to 5.3, we would not be able to use 5.4 features in the entire 1.0 series. By adopting 5.4 early (not that early, we're within the curve) we allow ourselves to use 5.4 specific features in following minor versions (1.1, 1.2).

Versioning is a subtle thing though. As we progress on the 1.0, we still need to keep the 0.9 series and estimate an ETA for deprecating it. As I see, deprecating 0.9 means deprecating 5.3 support, as both of these are attached to our major BC breaks and its such a good timing for doing so.

henriquemoody commented 9 years ago

As I already said, I'm :+1: for that because keeping an old version of PHP is a PITA.

Recently I bumped up PHP version to 5.3.6 - 96f4fc2, which I have to revert, BTW - because a unavailable method on the SplFileInfo class and that was just a tiny problem on sticking with this version, but there are others as you can imagine.

About the versions and the BC breaks, well, I have no intention to do that, but since we have no stable version yet, we can break API as much as we need, otherwise we probably were at version 3 or 4 - I'm not sure.

My plans were to have version 1.0 as First Major Version with the New Concrete API (#354), but seems 2.0 is a better name since we don't have a stable version with the current Concrete API and we won't have one, as far as I know.

IMHO, there is no practical reason to drop support PHP 5.3 support on the current codebase we have, as you can see I've put this issue on 1.0 milestone, see #258.

augustohp commented 9 years ago

Versioning is a subtle thing though. As we progress on the 1.0, we still need to keep the 0.9 series and estimate an ETA for deprecating it. As I see, deprecating 0.9 means deprecating 5.3 support, as both of these are attached to our major BC breaks and its such a good timing for doing so.

I think that talking about major versions is far better, if we consider current 0.9 as 1.*, makes more sense to me saying 1.* is 5.3 compatible. Keeping a 0.* as a stable major may not be against the rules but usually means an beta stage which I clearly think we are not into. Transmitting this message is an important thing IMO.

My plans were to have version 1.0 as First Major Version with the New Concrete API (#354), but seems 2.0 is a better name since we don't have a stable version with the current Concrete API and we won't have one, as far as I know.

IMHO, there is no practical reason to drop support PHP 5.3 support on the current codebase we have, as you can see I've put this issue on 1.0 milestone, see #258.

I agree with you with the new concrete API being 2.0. But, as I said above, I disagree on keeping 0.9 as the stable version. I would rather rename current efforts as the 2.0 milestone and create a simple 1.0 milestone with the current API as-is.

henriquemoody commented 9 years ago

I agree with you with the new concrete API being 2.0. But, as I said above, I disagree on keeping 0.9 as the stable version. I would rather rename current efforts as the 2.0 milestone and create a simple 1.0 milestone with the current API as-is.

IMHO, creating 1.0 is not a good idea. Actually having no stable version until you really figure out how your code must work is a good thing. If we create a 1.0 version we're gonna have a deficient stable version, with a lot of bugs and limitations we already know.

I can agree on jumping to 2.0 but not on creating a 1.0 version with our current code base. Any way, that's something we should discuss on #258, not here.

PS.: I will be offline for the next 15 days, when I get back we can discuss more about versions, plus release cycles.

augustohp commented 9 years ago

IMHO, creating 1.0 is not a good idea. Actually having no stable version until you really figure out how your code must work is a good thing.

Hmn, I have problems with that. Current API is used on a lot of places and is old (>3 years) and people using it is a kind of test I am most in favor not to ignore.

Although I really don't care with the name of the version, I have a very strong feeling towards marking the last package of the currently API as stable. After all, there are ~13k installs/month and 55 open source dependencies on this API.

If we create a 1.0 version we're gonna have a deficient stable version, with a lot of bugs and limitations we already know.

Having a stable version is contrary to have a bug free version. We aim to that but we may never achieve it. Having the amount of installs we currently have is a testament to the current api stability itself IMO.

I would not care to maintain it though, just flag and fix huge-deal-breaker bugs in respect to the people using the library for the past years.

henriquemoody commented 9 years ago

Fixed by c975dea.