On Tue, 2010-08-10 at 16:14 +0100, Derick Rethans wrote: > On Tue, 10 Aug 2010, Johannes Schlüter wrote: > > > On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote: > > > Is LTS really something we need to provide? Seems to me like this is > > > something the linux vendors take care of for the most part. Of course > > > this leaves windows, OSX (and maybe some others). > > > > Well, I don't see it as loooooooooooooooooooooooooong term support, but > > Using LTS as a term confused me on that one :P
Yeah, I didn't focus on the release earl, often fact enough. > > rather as way to enable quick feature cycles, so that feature releases > > can move faster than anybody can upgrade to them (ok, that's a bit too > > fast the, but hope you get the point), while new features can get in > > production sooner, where wanted. > > > > We could also use the names "feature preview release" and "stable > > release"(=lts) ... which would bring us close to MySQL's model and their > > confusing version numbering (MySQL 5.1 is the stable there, then MySQL > > 5.4 was announced as preview, now MySQL 5.5 is the current preview > > release, neither 5.4 nor 5.5 are "stable", "GA", though) > > I still don't think this is a good idea though. That would me we have > (as example) 5.2 in LTS, 5.6 as stable and 5.7 in trunk? How much do you > (at that point) like supporting a 4/5 year old version? Do you hvae that > much spare time? > > I think our current way work pretty well. There is 5.2 which is > security-fix supported, 5.3 that is supported and trunk/5.4 that's on > the way to alpha. Well, maintaining them becomes simpler if we change less features. Like adding a new SAPI in x.y.3 and lots of stuff in x.y.2. And for doing this we need shorter cycles. There is always small stuff, like simple functions, which misses a .0 release. Now committing them to trunk means they appear for earl adapters for the next version 1.5 to 2 years later. For the developers it is is stupid to hold a small "harmless" addition back so what are we doing - we're backporting stuff. Tons of stuff. If we shorten the cycle by which features become available in a "stable"/"feature preview"/... version we do have to care less about backporting, which makes handling of the released branches simpler. On the other side short cycles are bad for getting people to migrate, that's why there are longer supported releases. Now having distributors doing the backporting is nice for our workload (distributor package -> bogus bug report) but then one has to choose a distribution where you like the environment (what inisystem, what packagemanager etc.) and which doesn't break the timezone database or something else. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
