View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000484 | Composr | core | public | 2012-05-13 04:03 | 2012-08-17 13:25 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Severity | Feature-request | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0000484: Drop legacy support (server-side) | ||||
| Description | Drop lots of legacy support... Anything less than MySQL 5.1 Anything less than PHP 5.2 | ||||
| Steps To Reproduce | Update our coding guidelines, our requirements (on website and docs), remove workarounds (e.g. our re-definition of file_get_contents) | ||||
| Tags | Risk: Deprecates functionality | ||||
| Attach Tags | |||||
| Time estimation (hours) | 1 | ||||
| Sponsorship open | |||||
|
|
Actually we've been much more conservative... Anything less than MySQL 4 Anything less than PHP 5.0 That suits our purposes. If people use newer versions, great -- more security, more performance. But for us to need them... Newer MySQL just means that we may end up writing SQL other drivers can't use. Newer PHP means supporting alternate coding styles that are a matter of preference rather than value IMO. I would rather the code stay consistent and not have Javagen compsci graduates demanding a different coding style due to their different way of thinking ;-). There's not compelling functionality in newer versions of PHP as far as I'm concerned, but there are other compelling things in newer PHP that users can leverage anyway without us changing our baseline support. If PHP5.4 was widely deployed, I'd go for that as that actually does have some compelling cleanups to the language, but that's too recent still. Maybe we'll leap from 5.0 to 6.0 in a few years. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-06-08 00:15 | Chris Graham | Tag Renamed | Deprecates functionality => Risk: Deprecates functionality |
