El grupo al cual envías entradas es un grupo Usenet. Si envías mensajes a este grupo, cualquier usuario de Internet podrá ver tu dirección de correo electrónico
I understand that support for Symfony 1.2 is supposed to end in November with the release of Symfony 1.3.
What practices, if any, in Symfony 1.2 code are expected to be incompatible with Symfony 1.3?
I know Symfony 1.3 won't be the huge change that Symfony 1.1/1.2 were. But I still don't think it's wise to drop support for practices considered valid in 1.2 the moment 1.3 appears.
Other long-established open source projects do not do this on such a scale. Valid PHP 5.0.x code runs on PHP 5.3.x, with deprecation warnings sometimes, but it runs. And 5.2.x is definitely still being actively supported after the release of 5.3.x.
It is very difficult to make responsible proposals to clients without ongoing support for at least the previous minor version series for Symfony.
I know Symfony 1.2 wasn't supposed to be an LTS release but the reality is that it was the first stable-enough-to-use release of Symfony since the end of the 1.0.x series, and people have migrated long term projects to it out of necessity. I strongly feel it should be supported for at least a year after the release of 1.3.
I also think it is appropriate to fix serious bugs like http://trac.symfony-project.org/ticket/6937 in the 1.2 series, making features work substantially as advertised unless the only possible fix is a backwards incompatible change. But I can live without embedded M2M relation forms ever working in 1.2. What I find difficult to live without is enough stability that the Symfony releases page doesn't frighten clients off.
BC breaks in a mature system should be a major-version thing (2.0, not 1.0), and there should be ongoing support of the previous major version for quite a while when they happen.
I love this framework - please help me sell it to my clients as something that will continue to work for at least a year. (:
-- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com
It has been difficult for us to explain to clients why the newest 1.2
release is only supported until 11/2009 when the next release isn't
out yet and the 1.0 release has support which is expiring only 2
months later.
This makes any kind of conservative long term planning very difficult.
If I'm starting a project today, do I pick the old release which will
expire in 3 months, the newest release which will expire in 1, or the
unfamiliar beta release?
On Wed, Oct 28, 2009 at 2:23 PM, Tom Boutell <t...@punkave.com> wrote:
> I understand that support for Symfony 1.2 is supposed to end in
> November with the release of Symfony 1.3.
> What practices, if any, in Symfony 1.2 code are expected to be
> incompatible with Symfony 1.3?
> I know Symfony 1.3 won't be the huge change that Symfony 1.1/1.2 were.
> But I still don't think it's wise to drop support for practices
> considered valid in 1.2 the moment 1.3 appears.
> Other long-established open source projects do not do this on such a
> scale. Valid PHP 5.0.x code runs on PHP 5.3.x, with deprecation
> warnings sometimes, but it runs. And 5.2.x is definitely still being
> actively supported after the release of 5.3.x.
> It is very difficult to make responsible proposals to clients without
> ongoing support for at least the previous minor version series for
> Symfony.
> I know Symfony 1.2 wasn't supposed to be an LTS release but the
> reality is that it was the first stable-enough-to-use release of
> Symfony since the end of the 1.0.x series, and people have migrated
> long term projects to it out of necessity. I strongly feel it should
> be supported for at least a year after the release of 1.3.
> I also think it is appropriate to fix serious bugs like
> http://trac.symfony-project.org/ticket/6937 in the 1.2 series, making
> features work substantially as advertised unless the only possible fix
> is a backwards incompatible change. But I can live without embedded
> M2M relation forms ever working in 1.2. What I find difficult to live
> without is enough stability that the Symfony releases page doesn't
> frighten clients off.
> BC breaks in a mature system should be a major-version thing (2.0, not
> 1.0), and there should be ongoing support of the previous major
> version for quite a while when they happen.
> I love this framework - please help me sell it to my clients as
> something that will continue to work for at least a year. (:
On Wed, Oct 28, 2009 at 19:38, David Brewer <david.bre...@gmail.com> wrote:
> +1 from me on this.
> It has been difficult for us to explain to clients why the newest 1.2
> release is only supported until 11/2009 when the next release isn't
> out yet and the 1.0 release has support which is expiring only 2
> months later.
> This makes any kind of conservative long term planning very difficult.
> If I'm starting a project today, do I pick the old release which will
> expire in 3 months, the newest release which will expire in 1, or the
> unfamiliar beta release?
> On Wed, Oct 28, 2009 at 2:23 PM, Tom Boutell <t...@punkave.com> wrote:
> > I understand that support for Symfony 1.2 is supposed to end in
> > November with the release of Symfony 1.3.
> > What practices, if any, in Symfony 1.2 code are expected to be
> > incompatible with Symfony 1.3?
> > I know Symfony 1.3 won't be the huge change that Symfony 1.1/1.2 were.
> > But I still don't think it's wise to drop support for practices
> > considered valid in 1.2 the moment 1.3 appears.
> > Other long-established open source projects do not do this on such a
> > scale. Valid PHP 5.0.x code runs on PHP 5.3.x, with deprecation
> > warnings sometimes, but it runs. And 5.2.x is definitely still being
> > actively supported after the release of 5.3.x.
> > It is very difficult to make responsible proposals to clients without
> > ongoing support for at least the previous minor version series for
> > Symfony.
> > I know Symfony 1.2 wasn't supposed to be an LTS release but the
> > reality is that it was the first stable-enough-to-use release of
> > Symfony since the end of the 1.0.x series, and people have migrated
> > long term projects to it out of necessity. I strongly feel it should
> > be supported for at least a year after the release of 1.3.
> > I also think it is appropriate to fix serious bugs like
> > http://trac.symfony-project.org/ticket/6937 in the 1.2 series, making
> > features work substantially as advertised unless the only possible fix
> > is a backwards incompatible change. But I can live without embedded
> > M2M relation forms ever working in 1.2. What I find difficult to live
> > without is enough stability that the Symfony releases page doesn't
> > frighten clients off.
> > BC breaks in a mature system should be a major-version thing (2.0, not
> > 1.0), and there should be ongoing support of the previous major
> > version for quite a while when they happen.
> > I love this framework - please help me sell it to my clients as
> > something that will continue to work for at least a year. (:
>> It has been difficult for us to explain to clients why the newest 1.2
>> release is only supported until 11/2009 when the next release isn't
>> out yet and the 1.0 release has support which is expiring only 2
>> months later.
>> This makes any kind of conservative long term planning very difficult.
>> If I'm starting a project today, do I pick the old release which will
>> expire in 3 months, the newest release which will expire in 1, or the
>> unfamiliar beta release?
Totally agreeing with this!
The current info on the website is really scary for clients. May be
re-word it to include community support or something?
On Thu, Oct 29, 2009 at 11:40 AM, Sid Ferreira <sid....@gmail.com> wrote:
> Honestly +1
> Even if it gets updates only once each 2 month...
> On Wed, Oct 28, 2009 at 19:38, David Brewer <david.bre...@gmail.com> wrote:
>> +1 from me on this.
>> It has been difficult for us to explain to clients why the newest 1.2
>> release is only supported until 11/2009 when the next release isn't
>> out yet and the 1.0 release has support which is expiring only 2
>> months later.
>> This makes any kind of conservative long term planning very difficult.
>> If I'm starting a project today, do I pick the old release which will
>> expire in 3 months, the newest release which will expire in 1, or the
>> unfamiliar beta release?
>> On Wed, Oct 28, 2009 at 2:23 PM, Tom Boutell <t...@punkave.com> wrote:
>> > I understand that support for Symfony 1.2 is supposed to end in
>> > November with the release of Symfony 1.3.
>> > What practices, if any, in Symfony 1.2 code are expected to be
>> > incompatible with Symfony 1.3?
>> > I know Symfony 1.3 won't be the huge change that Symfony 1.1/1.2 were.
>> > But I still don't think it's wise to drop support for practices
>> > considered valid in 1.2 the moment 1.3 appears.
>> > Other long-established open source projects do not do this on such a
>> > scale. Valid PHP 5.0.x code runs on PHP 5.3.x, with deprecation
>> > warnings sometimes, but it runs. And 5.2.x is definitely still being
>> > actively supported after the release of 5.3.x.
>> > It is very difficult to make responsible proposals to clients without
>> > ongoing support for at least the previous minor version series for
>> > Symfony.
>> > I know Symfony 1.2 wasn't supposed to be an LTS release but the
>> > reality is that it was the first stable-enough-to-use release of
>> > Symfony since the end of the 1.0.x series, and people have migrated
>> > long term projects to it out of necessity. I strongly feel it should
>> > be supported for at least a year after the release of 1.3.
>> > I also think it is appropriate to fix serious bugs like
>> > http://trac.symfony-project.org/ticket/6937 in the 1.2 series, making
>> > features work substantially as advertised unless the only possible fix
>> > is a backwards incompatible change. But I can live without embedded
>> > M2M relation forms ever working in 1.2. What I find difficult to live
>> > without is enough stability that the Symfony releases page doesn't
>> > frighten clients off.
>> > BC breaks in a mature system should be a major-version thing (2.0, not
>> > 1.0), and there should be ongoing support of the previous major
>> > version for quite a while when they happen.
>> > I love this framework - please help me sell it to my clients as
>> > something that will continue to work for at least a year. (:
Yes please, as a developer on sf 1.0 for more than 2 years, i have no reason to convince my clients or even myself on migrating to newer version since it's no longer supported. And think about most of the plugins that are 1.2 compatible!
On Oct 28, 2009 10:38 PM, "David Brewer" <david.bre...@gmail.com> wrote:
+1 from me on this.
It has been difficult for us to explain to clients why the newest 1.2 release is only supported until 11/2009 when the next release isn't out yet and the 1.0 release has support which is expiring only 2 months later.
This makes any kind of conservative long term planning very difficult. If I'm starting a project today, do I pick the old release which will expire in 3 months, the newest release which will expire in 1, or the unfamiliar beta release?
On Wed, Oct 28, 2009 at 2:23 PM, Tom Boutell <t...@punkave.com> wrote: > > I
I love this framework too and in production mode i use only 1.0 version. I'm really afraid that Symfony could not be the success that it deserves. why? because backward compatibility is not supported with different version of the framework, critic behavior's interface like email or configuration are changed on every version. Maybe, it would be safe to slow the releases and trace a stable roadmap for a LTS version. I think that this discussion is really critic, so i hope that someone like fabien would react.
Le mercredi 28 octobre 2009 à 17:23 -0400, Tom Boutell a écrit :
> I understand that support for Symfony 1.2 is supposed to end in > November with the release of Symfony 1.3.
> What practices, if any, in Symfony 1.2 code are expected to be > incompatible with Symfony 1.3?
> I know Symfony 1.3 won't be the huge change that Symfony 1.1/1.2 were. > But I still don't think it's wise to drop support for practices > considered valid in 1.2 the moment 1.3 appears.
> Other long-established open source projects do not do this on such a > scale. Valid PHP 5.0.x code runs on PHP 5.3.x, with deprecation > warnings sometimes, but it runs. And 5.2.x is definitely still being > actively supported after the release of 5.3.x.
> It is very difficult to make responsible proposals to clients without > ongoing support for at least the previous minor version series for > Symfony.
> I know Symfony 1.2 wasn't supposed to be an LTS release but the > reality is that it was the first stable-enough-to-use release of > Symfony since the end of the 1.0.x series, and people have migrated > long term projects to it out of necessity. I strongly feel it should > be supported for at least a year after the release of 1.3.
> I also think it is appropriate to fix serious bugs like > http://trac.symfony-project.org/ticket/6937 in the 1.2 series, making > features work substantially as advertised unless the only possible fix > is a backwards incompatible change. But I can live without embedded > M2M relation forms ever working in 1.2. What I find difficult to live > without is enough stability that the Symfony releases page doesn't > frighten clients off.
> BC breaks in a mature system should be a major-version thing (2.0, not > 1.0), and there should be ongoing support of the previous major > version for quite a while when they happen.
> I love this framework - please help me sell it to my clients as > something that will continue to work for at least a year. (:
> I know Symfony 1.3 won't be the huge change that Symfony 1.1/1.2 were. > But I still don't think it's wise to drop support for practices > considered valid in 1.2 the moment 1.3 appears.
We don't drop working practices, symfony 1.3 is mainly about adding some polish to the whole framework, and needed features like email support. And projects running with symfony 1.2 are really easy to upgrade to symfony 1.3, thanks to the project:upgrade task. I have already upgraded several projects without a single problem. Of course, your mileage might vary, but I quite confident that it won't be a huge problem.
> Other long-established open source projects do not do this on such a > scale. Valid PHP 5.0.x code runs on PHP 5.3.x, with deprecation > warnings sometimes, but it runs. And 5.2.x is definitely still being > actively supported after the release of 5.3.x.
PHP is probably the worst piece of software in this regard. Backward compatibility can be broken at any time, in any minor version. And as a matter of fact, each release of PHP (even minor ones) actually introduces regressions, or backward incompatibilities which needs to be taken care of in symfony. And sometimes, the changes are radical.
I'm not trying to justify the changes we make in symfony, but frankly, the symfony 1.3 version is really about cosmetic changes.
> It is very difficult to make responsible proposals to clients without > ongoing support for at least the previous minor version series for > Symfony.
But what keeps you from using symfony 1.2 even after November 2009? If your projects work, there is no need to upgrade. Can you tell me what kind of support you have on other big frameworks? I think symfony is probably one the few to have such a clear policy regarding support. And as far as I know, even PHP doesn't have such a clear support policy.
Keep in mind that symfony is an Open-Source project, so everybody can contribute and scratch its itch. The core developers and all plugin developers are all working for free. Of course, Sensio sponsors the framework, of course it dedicates a lot of time and money to it, and of it can even provide extended support for all versions for companies willing to pay. And do you know how many companies, except Sensio customers, signed up for extended support in the last 2 years? None! Yep, that's right, not a single one.
> I know Symfony 1.2 wasn't supposed to be an LTS release but the > reality is that it was the first stable-enough-to-use release of > Symfony since the end of the 1.0.x series, and people have migrated > long term projects to it out of necessity. I strongly feel it should > be supported for at least a year after the release of 1.3.
The fact that symfony 1.2 would have a year of support has been public since long before it was released. So people made their decisions consciously. And again, symfony 1.3 is not that difficult to upgrade to.
> I also think it is appropriate to fix serious bugs like > http://trac.symfony-project.org/ticket/6937 in the 1.2 series, making > features work substantially as advertised unless the only possible fix > is a backwards incompatible change. But I can live without embedded > M2M relation forms ever working in 1.2. What I find difficult to live > without is enough stability that the Symfony releases page doesn't > frighten clients off.
> BC breaks in a mature system should be a major-version thing (2.0, not > 1.0), and there should be ongoing support of the previous major > version for quite a while when they happen.
We have always tried to find a good balance between moving the project forward (like adding new features) and keeping backward compatibility. With symfony, we try to document every single change we make and for most of the changes, and the project:upgrade task mostly does all the upgrading work for you.
> I love this framework - please help me sell it to my clients as > something that will continue to work for at least a year. (:
There were a talk before on an extended community support until June 2010. Apparently it went nowhere as I have not heard about that since a long time. I have no problem supporting symfony 1.2 longer, but people who want this extended support should also probably be able to help us.
frédéric gontier wrote:
> I love this framework too and in production mode i use only 1.0 version.
> I'm really afraid that Symfony could not be the success that it
> deserves.
> why? because backward compatibility is not supported with different
> version of the framework, critic behavior's interface like email or
> configuration are changed on every version. Maybe, it would be safe to
> slow the releases and trace a stable roadmap for a LTS version.
> I think that this discussion is really critic, so i hope that someone
> like fabien would react.
> Le mercredi 28 octobre 2009 à 17:23 -0400, Tom Boutell a écrit :
> > I understand that support for Symfony 1.2 is supposed to end in
> > November with the release of Symfony 1.3.
> > What practices, if any, in Symfony 1.2 code are expected to be
> > incompatible with Symfony 1.3?
> > I know Symfony 1.3 won't be the huge change that Symfony 1.1/1.2 were.
> > But I still don't think it's wise to drop support for practices
> > considered valid in 1.2 the moment 1.3 appears.
> > Other long-established open source projects do not do this on such a
> > scale. Valid PHP 5.0.x code runs on PHP 5.3.x, with deprecation
> > warnings sometimes, but it runs. And 5.2.x is definitely still being
> > actively supported after the release of 5.3.x.
> > It is very difficult to make responsible proposals to clients without
> > ongoing support for at least the previous minor version series for
> > Symfony.
> > I know Symfony 1.2 wasn't supposed to be an LTS release but the
> > reality is that it was the first stable-enough-to-use release of
> > Symfony since the end of the 1.0.x series, and people have migrated
> > long term projects to it out of necessity. I strongly feel it should
> > be supported for at least a year after the release of 1.3.
> > I also think it is appropriate to fix serious bugs like
> > http://trac.symfony-project.org/ticket/6937 in the 1.2 series, making
> > features work substantially as advertised unless the only possible fix
> > is a backwards incompatible change. But I can live without embedded
> > M2M relation forms ever working in 1.2. What I find difficult to live
> > without is enough stability that the Symfony releases page doesn't
> > frighten clients off.
> > BC breaks in a mature system should be a major-version thing (2.0, not
> > 1.0), and there should be ongoing support of the previous major
> > version for quite a while when they happen.
> > I love this framework - please help me sell it to my clients as
> > something that will continue to work for at least a year. (:
After discussing the matter with the core team and especially Fabian
(the release manager of symfony 1.2), we have decided to extend the
support for symfony 1.2 for another 3 months. 3 months of overlap
seems like plenty of time to migrate your applications. The
installation page will be updated accordingly.
Fabien
On Nov 2, 8:18 am, Fabien Potencier <fabien.potenc...@symfony-
project.com> wrote:
> frédéric gontier wrote:
> > I love this framework too and in production mode i use only 1.0 version.
> > I'm really afraid that Symfony could not be the success that it
> > deserves.
> > why? because backward compatibility is not supported with different
> > version of the framework, critic behavior's interface like email or
> > configuration are changed on every version. Maybe, it would be safe to
> > slow the releases and trace a stable roadmap for a LTS version.
> > I think that this discussion is really critic, so i hope that someone
> > like fabien would react.
> I have just answered to the original email.
> Fabien
> > Le mercredi 28 octobre 2009 à 17:23 -0400, Tom Boutell a écrit :
> > > I understand that support for Symfony 1.2 is supposed to end in
> > > November with the release of Symfony 1.3.
> > > What practices, if any, in Symfony 1.2 code are expected to be
> > > incompatible with Symfony 1.3?
> > > I know Symfony 1.3 won't be the huge change that Symfony 1.1/1.2 were.
> > > But I still don't think it's wise to drop support for practices
> > > considered valid in 1.2 the moment 1.3 appears.
> > > Other long-established open source projects do not do this on such a
> > > scale. Valid PHP 5.0.x code runs on PHP 5.3.x, with deprecation
> > > warnings sometimes, but it runs. And 5.2.x is definitely still being
> > > actively supported after the release of 5.3.x.
> > > It is very difficult to make responsible proposals to clients without
> > > ongoing support for at least the previous minor version series for
> > > Symfony.
> > > I know Symfony 1.2 wasn't supposed to be an LTS release but the
> > > reality is that it was the first stable-enough-to-use release of
> > > Symfony since the end of the 1.0.x series, and people have migrated
> > > long term projects to it out of necessity. I strongly feel it should
> > > be supported for at least a year after the release of 1.3.
> > > I also think it is appropriate to fix serious bugs like
> > >http://trac.symfony-project.org/ticket/6937in the 1.2 series, making
> > > features work substantially as advertised unless the only possible fix
> > > is a backwards incompatible change. But I can live without embedded
> > > M2M relation forms ever working in 1.2. What I find difficult to live
> > > without is enough stability that the Symfony releases page doesn't
> > > frighten clients off.
> > > BC breaks in a mature system should be a major-version thing (2.0, not
> > > 1.0), and there should be ongoing support of the previous major
> > > version for quite a while when they happen.
> > > I love this framework - please help me sell it to my clients as
> > > something that will continue to work for at least a year. (:
I would like to add that support means that the core team will invest time on ticket triageing, providing patches, analyzing problems and such stuff. However more problems will get solved when there are more patches posted to trac. And those patches could deserve a community review. -> You will get better support if you help us.
I don't work for Sensio, I am doing this in my free time and to a tiny extend sponsored by my company. If you say you need support for symfony you should also consider buying it from Sensio. This is the only way for guaranteed timely response.
Having said that, I would like to ask you also to contribute to the upcoming BugHuntDay. I will be there and we should try to backport fixes. But because we are restricted to fixes only, we can still do cool stuff in 1.3.
Now you have 3 more months for upgrade. But if you upgrade early, you can still influence the content of the 1.3 release, making your app better and making symfony better.
> After discussing the matter with the core team and especially Fabian > (the release manager of symfony 1.2), we have decided to extend the > support for symfony 1.2 for another 3 months. 3 months of overlap > seems like plenty of time to migrate your applications. The > installation page will be updated accordingly.
I'd just like to cap off this conversation by reiterating Fabien's
earlier comment about a smooth upgrade from 1.2 to 1.3. There are a
number of trivial changes, such as modified function signatures, that
we have rolled back because of the remote possibility they may cause
STRICT errors to be thrown upon upgrade. We want this to be that easy.
If you've upgraded a project and run into issues we haven't addressed
in the upgrade task, please take the 5 minutes to post a ticket to
Trac and tell us about it. We will do our best to address it.
Thanks,
Kris
--
Kris Wallsmith | Release Manager
kris.wallsm...@symfony-project.com
Portland, Oregon USA
> I would like to add that support means that the core team will invest
> time on ticket triageing, providing patches, analyzing problems and
> such stuff. However more problems will get solved when there are more
> patches posted to trac. And those patches could deserve a community
> review.
> -> You will get better support if you help us.
> I don't work for Sensio, I am doing this in my free time and to a tiny
> extend sponsored by my company.
> If you say you need support for symfony you should also consider
> buying it from Sensio. This is the only way for guaranteed timely
> response.
> Having said that, I would like to ask you also to contribute to the
> upcoming BugHuntDay. I will be there and we should try to backport
> fixes.
> But because we are restricted to fixes only, we can still do cool
> stuff in 1.3.
> Now you have 3 more months for upgrade. But if you upgrade early, you
> can still influence the content of the 1.3 release, making your app
> better and making symfony better.
> Fabian
> On Mon, Nov 2, 2009 at 1:13 PM, Fabien Potencier
> <fabien.potenc...@symfony-project.com> wrote:
>> After discussing the matter with the core team and especially Fabian
>> (the release manager of symfony 1.2), we have decided to extend the
>> support for symfony 1.2 for another 3 months. 3 months of overlap
>> seems like plenty of time to migrate your applications. The
>> installation page will be updated accordingly.
i guess that would be nice as well every ticket open to be highly
documented, and maybe as more specific steps to reproduce it ...
No one would like hear things like: "i have upgraded my sf project.. and now
is not working anymore"
Also, another thing that Fabian already mentioned it... you run in the
problems, try to fix it and post a patch or a ticket with the problem you
had and also the fix of it.
Alecs
kris.wallsm...@symfony-project.com> wrote:
> Hi everyone,
> I'd just like to cap off this conversation by reiterating Fabien's earlier
> comment about a smooth upgrade from 1.2 to 1.3. There are a number of
> trivial changes, such as modified function signatures, that we have rolled
> back because of the remote possibility they may cause STRICT errors to be
> thrown upon upgrade. We want this to be that easy.
> If you've upgraded a project and run into issues we haven't addressed in
> the upgrade task, please take the 5 minutes to post a ticket to Trac and
> tell us about it. We will do our best to address it.
> I would like to add that support means that the core team will invest
> time on ticket triageing, providing patches, analyzing problems and
> such stuff. However more problems will get solved when there are more
> patches posted to trac. And those patches could deserve a community
> review.
> -> You will get better support if you help us.
> I don't work for Sensio, I am doing this in my free time and to a tiny
> extend sponsored by my company.
> If you say you need support for symfony you should also consider
> buying it from Sensio. This is the only way for guaranteed timely
> response.
> Having said that, I would like to ask you also to contribute to the
> upcoming BugHuntDay. I will be there and we should try to backport
> fixes.
> But because we are restricted to fixes only, we can still do cool stuff in
> 1.3.
> Now you have 3 more months for upgrade. But if you upgrade early, you
> can still influence the content of the 1.3 release, making your app
> better and making symfony better.
> Fabian
> On Mon, Nov 2, 2009 at 1:13 PM, Fabien Potencier
> <fabien.potenc...@symfony-project.com> wrote:
> After discussing the matter with the core team and especially Fabian
> (the release manager of symfony 1.2), we have decided to extend the
> support for symfony 1.2 for another 3 months. 3 months of overlap
> seems like plenty of time to migrate your applications. The
Fabien, thank you for extending support for another three months and
emphasizing how straightforward the upgrade to Symfony 1.3 will be.
Going forward into the future I think it would be a smart marketing
decision to always provide at least three months of overlap in
situations like these.
I definitely see your point about the Sensio paid support option. I'll
be keeping that in mind when clients get antsy about support for
long-established projects. My more immediate concern was with an
earlier stage of negotiations. Without the three-month overlap it
would have been hard to sell a technically astute client on the
framework... the timing was very awkward.
> After discussing the matter with the core team and especially Fabian
> (the release manager of symfony 1.2), we have decided to extend the
> support for symfony 1.2 for another 3 months. 3 months of overlap
> seems like plenty of time to migrate your applications. The
> installation page will be updated accordingly.
> Fabien
> On Nov 2, 8:18 am, Fabien Potencier <fabien.potenc...@symfony-
> project.com> wrote:
>> frédéric gontier wrote:
>> > I love this framework too and in production mode i use only 1.0 version.
>> > I'm really afraid that Symfony could not be the success that it
>> > deserves.
>> > why? because backward compatibility is not supported with different
>> > version of the framework, critic behavior's interface like email or
>> > configuration are changed on every version. Maybe, it would be safe to
>> > slow the releases and trace a stable roadmap for a LTS version.
>> > I think that this discussion is really critic, so i hope that someone
>> > like fabien would react.
>> I have just answered to the original email.
>> Fabien
>> > Le mercredi 28 octobre 2009 à 17:23 -0400, Tom Boutell a écrit :
>> > > I understand that support for Symfony 1.2 is supposed to end in
>> > > November with the release of Symfony 1.3.
>> > > What practices, if any, in Symfony 1.2 code are expected to be
>> > > incompatible with Symfony 1.3?
>> > > I know Symfony 1.3 won't be the huge change that Symfony 1.1/1.2 were.
>> > > But I still don't think it's wise to drop support for practices
>> > > considered valid in 1.2 the moment 1.3 appears.
>> > > Other long-established open source projects do not do this on such a
>> > > scale. Valid PHP 5.0.x code runs on PHP 5.3.x, with deprecation
>> > > warnings sometimes, but it runs. And 5.2.x is definitely still being
>> > > actively supported after the release of 5.3.x.
>> > > It is very difficult to make responsible proposals to clients without
>> > > ongoing support for at least the previous minor version series for
>> > > Symfony.
>> > > I know Symfony 1.2 wasn't supposed to be an LTS release but the
>> > > reality is that it was the first stable-enough-to-use release of
>> > > Symfony since the end of the 1.0.x series, and people have migrated
>> > > long term projects to it out of necessity. I strongly feel it should
>> > > be supported for at least a year after the release of 1.3.
>> > > I also think it is appropriate to fix serious bugs like
>> > >http://trac.symfony-project.org/ticket/6937in the 1.2 series, making
>> > > features work substantially as advertised unless the only possible fix
>> > > is a backwards incompatible change. But I can live without embedded
>> > > M2M relation forms ever working in 1.2. What I find difficult to live
>> > > without is enough stability that the Symfony releases page doesn't
>> > > frighten clients off.
>> > > BC breaks in a mature system should be a major-version thing (2.0, not
>> > > 1.0), and there should be ongoing support of the previous major
>> > > version for quite a while when they happen.
>> > > I love this framework - please help me sell it to my clients as
>> > > something that will continue to work for at least a year. (:
-- Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
Thanks for making this change. Those 3 months of overlap don't make a big
difference to me as a developer, but they make a huge difference when trying
to explain the symfony roadmap to a client.
David
On Mon, Nov 2, 2009 at 4:13 AM, Fabien Potencier <
> After discussing the matter with the core team and especially Fabian
> (the release manager of symfony 1.2), we have decided to extend the
> support for symfony 1.2 for another 3 months. 3 months of overlap
> seems like plenty of time to migrate your applications. The
> installation page will be updated accordingly.
> Fabien
> On Nov 2, 8:18 am, Fabien Potencier <fabien.potenc...@symfony-
> project.com> wrote:
> > frédéric gontier wrote:
> > > I love this framework too and in production mode i use only 1.0
> version.
> > > I'm really afraid that Symfony could not be the success that it
> > > deserves.
> > > why? because backward compatibility is not supported with different
> > > version of the framework, critic behavior's interface like email or
> > > configuration are changed on every version. Maybe, it would be safe to
> > > slow the releases and trace a stable roadmap for a LTS version.
> > > I think that this discussion is really critic, so i hope that someone
> > > like fabien would react.
> > I have just answered to the original email.
> > Fabien
> > > Le mercredi 28 octobre 2009 à 17:23 -0400, Tom Boutell a écrit :
> > > > I understand that support for Symfony 1.2 is supposed to end in
> > > > November with the release of Symfony 1.3.
> > > > What practices, if any, in Symfony 1.2 code are expected to be
> > > > incompatible with Symfony 1.3?
> > > > I know Symfony 1.3 won't be the huge change that Symfony 1.1/1.2
> were.
> > > > But I still don't think it's wise to drop support for practices
> > > > considered valid in 1.2 the moment 1.3 appears.
> > > > Other long-established open source projects do not do this on such a
> > > > scale. Valid PHP 5.0.x code runs on PHP 5.3.x, with deprecation
> > > > warnings sometimes, but it runs. And 5.2.x is definitely still being
> > > > actively supported after the release of 5.3.x.
> > > > It is very difficult to make responsible proposals to clients
> without
> > > > ongoing support for at least the previous minor version series for
> > > > Symfony.
> > > > I know Symfony 1.2 wasn't supposed to be an LTS release but the
> > > > reality is that it was the first stable-enough-to-use release of
> > > > Symfony since the end of the 1.0.x series, and people have migrated
> > > > long term projects to it out of necessity. I strongly feel it should
> > > > be supported for at least a year after the release of 1.3.
> > > > I also think it is appropriate to fix serious bugs like
> > > >http://trac.symfony-project.org/ticket/6937in the 1.2 series, making
> > > > features work substantially as advertised unless the only possible
> fix
> > > > is a backwards incompatible change. But I can live without embedded
> > > > M2M relation forms ever working in 1.2. What I find difficult to
> live
> > > > without is enough stability that the Symfony releases page doesn't
> > > > frighten clients off.
> > > > BC breaks in a mature system should be a major-version thing (2.0,
> not
> > > > 1.0), and there should be ongoing support of the previous major
> > > > version for quite a while when they happen.
> > > > I love this framework - please help me sell it to my clients as
> > > > something that will continue to work for at least a year. (:
I try yo follow all this conversation and below are things I need to say:
1) You don't pay for support means you don't need support:
I'm happy enough that symfony developers offer free support/upgrade until the next version. I don't pay for support because I think that I've enough experience in PHP development to read the source code and understand how does it work. If I see any bug (or dysfunction), I try to find a workaround and submit it at the right place on the web for other developers that encounter the same trouble...
2) Your symfony version is not updated anymore, patch it yourself:
Remove the SVN external link on your symfony librairy (if you have one) and work on your own subversion of symfony library. I never had to patch anything because I can extend everything to my own classes that does corrections and/or add features. Helping the factory system, I'm able to tell the symfony core to use my classes insteed of the default ones.
By example: I would like to be able to dynamically add methods to the sfUser class (because I have a lot of plugins that deal with users and I cannot do multiple extension on my main user class). I know that symfony offer a way to dynamically add methods to any object, unfortunely it does not seem to be apply on sfUser classes when a method does not exist. Ok, I look how does it works and I had this new feature on my custom main user class. I tell symfony core to use my brand new user class and that's all, I have a new feature and I didn't touch the symfony core. Am I a genius ? I don't think so...
3) 3 months extension support, you're too nice and it will lose you:
From my not-marketer point of vue, if community wants support, community support is the better solution. People that want to use the previous symfony versions can still work on it, submit their patch or anything else, and symfony team can really focus on the latest version without having to worry about old code. If I have to choose beetween past or future, I vote for future. Evolution is the most important thing in the entire universe, and it must never stop, especially for an open source project...
4) Your clients care about support on their symfony version, you're a lucky developer:
I never had any client that cares about its symfony version, most of them just want their web site to work the way they want it to work. When I have to explain to a client why I'm using symfony instead of Drupal (sploosh... did anybody have heard about OOP?), Magento (glub glub... can i just do something?) or other shit (ie. Joomla!, Typo3, etc.), I try to explain at him how a framework is better than any CMS and why symfony is the best framework that I had ever seen. My most famous arguments are flexibility, usage of all latest PHP technologies, security features and flexibility.
Sorry for this boring novel, and sorry if I seem agressive. Please, don't take any part of it as personnal attack and do not hesitate if you want to argue.
Loops
NB: For my personnal context, I'm have a bunch of projects under every symfony version (1.1 include) and I had never see any insurmountable barriers. If my client wants some major changes that really need upgrade, I just take care about that in my cost estimation.
|
