On Tue, 2010-08-10 at 17:25 +0800, Adam Harvey wrote: > – The LTS branch is going to become more and more difficult to > backport fixes to as it diverges from the other two branches, and I > can see developers not bothering after a certain point, which may be > counter productive.
Except for things like the Unicode branch our code base is quite stable in most places. > – Documenting how functionality changes from version to version in the > manual is already a weak point, judging by some of the bugs and > feedback we get: users don't always grok the version bylines and > change log tables in the function reference as it is, and that's with > a more closely aligned set of active branches. We might end up needing > to rethink how we structure the manual by looking at something like > the Python approach of having separate manuals for separate versions, > which would require a not-insignificant amount of work. In the LTS the functionality shouldn't change (having shorter cycles even between other bug fix releases) Yes there are exceptions where a needed bug fix has an effect, but documenting this should be solvable. > – It might be hard to communicate why 5.4 (in the example you > included) becomes end of lifed while 5.3 lives on. I guess that's no > different to Ubuntu, though. Better naming than simply "5.3", "5.4" ... might help. But should be solvable. > – Will downstream distributors want to ship non-LTS versions? This > might actually reduce the amount of useful feedback we get for (again, > using your example) 5.4, 5.5 and 5.6 releases, which might not be a > great thing for the stability of the next LTS (6.0) release. Distributors should be able to distribute two versions. Some do/did with PHP 4 and PHP 5. And I prefer distributions offering the bug fix releases for the LTS version over a heavily patched outdated 5.1.6 like RedHat does. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
