Google Groups

Re: [symfony-devs] Symfony 2.1 release


Florin Patan Apr 30, 2012 7:36 AM
Posted in group: Symfony developers (DISABLED)
Hi,

Besides the fact that this is starting the wrong way, I do believe that there's also a confusion being done between LTS and Stable.
IMHO LTS = Stable but with less newer features.

Now, if you are going to write a good application, or a multi-million $ app, then you should be able upgrade the framework behind it pretty easy unless really BIG BC breaks appear between versions (see Forms). And if you have the multi-million $ business in the first place, then I do believe your programmers will be able to upgrade the application pretty fast.

I'm currently running master against a production env with a couple of countries, a couple of million of users (and I'm not allowed to say more) but the upgrade from 2.0.7 (if I recall it correctly) to master was pretty painless, only 3 days or so to migrate the code, run the automated tests, check for the performance gains/drops and so on and it feels pretty good when I can do an upgrade with little to no effort all by myself, so that the rest of the team can focus on development. I'd say master is very stable for us so far, using it since 1st of February and I see no reason for using a LTSĀ  (I do hope my manager won't see this as LTS sounds so good when you present it to someone...). But the point is: Symfony2 should have only stable releases and as far far as LTSes go.. they can be very well in 2.12.0 as far as I care.

And to be back on topic... Master already has some large changes so we should rather finish the changes for Form, make it stable then push 2.1 and then start doing smaller release cycles with less BC breaks as the current upgrade.


Kind regards,
Florin

On Monday, April 30, 2012 4:57:39 PM UTC+3, Matt Robinson wrote:
On 30 Apr 2012, at 14:07, Thomas Lundquist wrote:

> On Mon, Apr 30, 2012 at 01:17:58PM +0100, Matt Robinson wrote:
>>
>> 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.
>
> I mean it's not long enough. If it were three years after a viable option
> to the LTS was around, ok. Right now the *only* LTS for Symfony is
> 1.4 which will be EOL in short time. Without any replacement.
>
> People will be using 1.4 based applications for way way longer than
> three years since 1.4.0 was released. It has been their only option for
> quite a lot of that time.
>
> Three years is not much of a life time of a big application, even
> disregarding COBOL/Bank systems that has life spans of 20-30 years.
>
> You do not want to write off a million dollar investment over three
> years, not everyone has the scope of "make it just run until we are
> bought and rich".

Sure, but if you make a million+ dollar investment built on Symfony, you can afford to pay for long term support from Sensio (or someone else). As far as I know, they're still offering commercial support for 1.0 (at least I remember Fabien saying something along those lines a while ago). The 3 year support is what you get for free, not the _only_ thing you can get. Since it's impossible to upgrade from 1.4 to 2.0, there'll be plenty of people running 1.4 projects for many years to come.


>> 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.
>
> Which is a concern today, there are no Symfony release I can trust will
> be supported for the *next* three years.
>
> And picking Symfony now is not easy, whatever you do you know you are
> going to have to change quite alot in short to middle term.

Why are you going to have to change anything? You only need to upgrade if:

1. There's a security fix, but security fixes don't break compatibility.
2. You aren't willing to accept community-only support, and aren't willing/able to pay for commercial support.
3. A plugin you're using is abandoned by its author, and then breaks (e.g. something that consumes a web service whose API changes). But that's a risk that applies regardless of how long Symfony itself is supported for.


>> 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.
>
> But no one will take responsibility for it and that should worry
> the users.
>
> And maybe scare them off from Symfony2 where the story seems to be the same.

Plenty of people will take responsibility for it if you pay them. We still support and actively maintain a number of projects built on Symfony 1.0 for our clients. It does mean that the burden of maintaining the platform has moved from Sensio to us, but on the other hand that burden is much smaller after 3+ years of stability and maintenance. If it goes wrong, we're experienced enough with it after 6 years that we can fix it without it costing us the earth.

We're confident enough that 1.4 will continue to be stable and useful for the next 3-5 years that we're developing new sites for clients with it right now. We tell our clients what the expected lifetime of a project is before they start, so that they can see how long they can expect to be able to have maintenance without a major upgrade. After 5 years on the web, it's definitely time to reevaluate the product anyway, for all kinds of other reasons than software versions (e.g. design & UX, feature-drift, competition, etc).

So to go back to your original question, "When can the users expect a Symfony release they can use for a few years without minor or major rewrites because of BC breaks?" the answer is that they've had that for at least the last 3 years, and this will remain the case for the foreseeable future, even though official support will probably end in November. If it's a matter of business continuity for you, then like everything else that's mission critical you probably have to pay for it.

-- Matt