2.5 branch added

[mark_story]

Hey everyone,

Since 2.4 has hit an RC stage, I've added a fresh branch for 2.5. Much like the other 2.x branches this branch should maintain backwards compatibility with other 2.x releases. It is also a good opportunity to backport some ideas and plans for new methods from 3.x.

Since there isn't much of a formal plan for 2.5 is there anything people want to see in it?

My list is:

- Add Security::encrypt() and Security::decrypt() as easy to use methods around AES-256 without the baggage that rijndael has or the hard to spell method name.

- Add the rekey shell task as rijndael will be BC incompatible for 3.x

-Mark

[Sebastiaan van Stijn]

I'm wondering if the system requirements for the 2.5 release can be updated or if that is only allowed for a major (3.x) release.

PHP requirements
Currently CakePHP 2.x supports PHP 5.2.8+, CakePHP requires PHP 5.4+. Since PHP 5.2 is no longer supported by PHP itself,
dropping support for it should be nothing to be ashamed of; Some code can be cleaned up and may make it easier to backport
improvements from the 3.0 branch into the 2.5 branch.

Database requirements
Database requirements may need an update as well; MySQL 5 was released in 2005, 5.1 in 2008 and 5.5 in 2010. I think it's safe
to (at least) move to 5.x as a requirement at some stage, maybe even one of the latter.

For PostgreSQL, SQL Server and SQLite, I see no version requirements at all;

PostgreSQL 8 was released in 2005; 8.4 is the currently supported version in the 8.x branch (http://www.postgresql.org/support/versioning/),
stating 8.3 or 8.4 as the minimum requirement for CakePHP 2.x sounds reasonable to me?

I don't have much to do with MS SQL Server and SQLite, so maybe someone can provide some thoughts on this?

Dropping support for ancient software can reduce the amount of code for 'backward compatibility' messing up the code-base.
Also, promoting support for software that is no longer maintained seems like 'bad practice' to me, especially considering the security issues this
may cause.

Finally, if it's only 'allowed' to change system requirements for a *major* release, will it be possible to discuss renaming the 2.5 branch to 3.0, and
3.0 to 4.0?

[Juan Basso]

I would love to see your implementation of routing aliases from 3.0 on 2.5, but not sure if it is viable without change all the routing structure.

--
You received this message because you are subscribed to the Google Groups "cakephp-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cakephp-core...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[euromark]

I agree, some of the 3.x things like Routing enhancements could be backported to 2.5 maybe (scheme, domain, ...)

[mark_story]

To be honest the project has not been in this specific situation before. A question I have is, if we were to move the requirements forward what the benefit be to 2.x? We couldn't really adopt namespaces as that would break backwards compatibility.

I worry that moving the version requirements forward to 5.3 will indicate the intention to support features from those versions in 2.x. Currently I (and to my knowledge others on the team) have no interest in duplicating the work between newer 2.x releases and 3.x

For SQLserver we only support SQLServer 2005+ as that is what PDO_sqlsrv supports. As for other databases I'm fine with moving the requirements forward. I don't think there is much in the way of conditional code for older versions of MySQL or Postgres to be honest.

In relation to backporting, I think it is a great idea if someone has the time and energy. I currently do not so I'm trying to focus on 3.0. I've always thought there were a number of features/changes we've done in 3.0 that could be backported if there was time/someone willing to do it.

-Mark

[Ravage84]

I also don't see much benefits, so I wouldn't push forward the system requirements for any 2.x release.

If you want to do, you could do it by stating that starting with CakePHP 2.5 it "officially" supports PHP 5.3+ only, for example.
But it "should" still support PHP 5.2.8+ as nothing was changed.
So tickets against CakePHP 2.5+ wouldn't get the same priority or wouldn't even get fixed if they are releated to a problem with PHP 5.2.x.

But in the end I personally see no real benefit in this.
Also it could introduce lots of misunderstadings and could even weaken the confidence in CakePHP within the community!

[mark_story]

Confusion is one of the main reasons I would like to not change any system requirements in 2.x

Unless there are compelling reasons and people with ample time to commit to the work I'd much prefer to leave the requirements for 2.x as they stand.

-Mark

[Reuben Helms]

I second that reason, but don't support the option of a compelling reason.

The CakePHP 2.x range has been going for a while, and most of my projects have been running PHP 5.2.x. I've been able to apply each update to the 2.x range with little fuss.

It would be a bit of a slap to suddenly not be able to update to 2.5, because it started only officially supported PHP 5.3, and new CakePHP functionality started making use libs that are only available in PHP 5.3.  It wouldn't be an issue until some security issue was discovered, and then you'd have to update 2.5, and I'd be hoping that 2.4 would also be updated.

Also, considering that PHP 5.3 is now in the End of Life cycle [http://php.net/archive/2013.php#id2013-07-11-1], it's going to be just as supported as PHP 5.2 in about 11 months.  I'd be hoping that CakePHP 3.0 is out by then.

It would be better to concentrate on getting new features into CakePHP 3.0, and pick up with PHP 5.4, especially when PHP 5.5 has been released.