On 30 Apr 2012, at 12:48, Thomas Lundquist wrote: > On Mon, Apr 30, 2012 at 12:20:42PM +0100, Matt Robinson wrote: >> >> Actually Symfony 1.0.x, 1.4.x and 2.0.x are exactly this way - they had/have >> long-term support and compatibility guarantees (this hasn't changed, right?) > > I haven't followed 1.0 alot so I have no idea if this is being supported > or not but 1.4 seems to be at least. > > 1.0 is not mentioned as an LTS here: > > http://www.symfony-project.org/installation
Right, it -had- 3 years of support, which are now long over. Sorry if I didn't make that clear. > Btw, an expiration of november 2012 for symfony 1.4 is way too early for > it to be called *long term* support. Why? It's 3 years: November 2009 to November 2012. Do you mean that there's not enough overlap between LTS releases? That's certainly regrettable. It doesn't mean 1.4 didn't enjoy long term support though. If there's going to be a long period where there's no release of Symfony with long term support, then that's obviously a concern. There's certainly a risk of this happening if 2.2 isn't released before November. I expect that 1.4 will continue to receive essential security and PHP-compatibility fixes for some time after November though. It's definitely not going to just stop working. > Regarding 2.0, if it is an LTS it's a well hidden secret on symfony.com, > I tried to find it but could not. Alot of blurb but no hints as far > as I could find. > > I would expect it both on the download page and in a few places > in points and pages linked to from http://symfony.com/what-is-symfony > > http://en.wikipedia.org/wiki/Symfony points at 2.2 as the first LTS for > Symfony 2. It's entirely likely that I'm wrong on this and 2.2 will be the first LTS. I was operating on memory alone and if I'm wrong, sorry! It certainly makes more sense to wait until the API is totally stabilised before declaring another LTS. Sorry to confuse the issue. >> It's pretty typical for long-term support releases of software to fail to >> get feature upgrades. It's the easiest way to guarantee stability. > > But of course, stability is the key. > > New features that does not break BC or API can be added, either as > backports or just plainly added. > > It's all about breakage and API. You can do alot with even a framework > while keeping the stability. > > In my view, you don't break API between minor versions. > > I guess I'm a dinosaur. I don't think you're a dinosaur, I just think you're applying an expectation about version numbering that hasn't been officially stated by the Symfony team. In the case of Symfony LTS releases in the past, the minor versions have been the 3rd digit, not the 2nd. The 2nd digit version number has nearly always broken compatibility in some ways (except for 1.3/1.4, where 1.4 was actually a subset of 1.3). Perhaps this should be made more clear, but it's at least internally consistent :) I'd like to see backports too, but only on LTS releases to keep them fresh. If 2.0 isn't one of them, then we're pretty much flying by the seat of our pants until 2.2 lands. Regards, -- Matt -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
