|Symfony 2.1 release||Fabien Potencier||4/27/12 11:09 AM|
The Symfony 2.1 release was expected to be published some time ago and
we struggle with it for two main reasons:
* The number of contributions we have every single day. That's great but
it means that it is never a good time to release because of this last
minute great change that we want to merge first;
* The recent BC breaks in the form/validator components.
But basically, we cannot release 2.1 because of the second point. We
need to be sure that we only break BC for forms only once. So, we have
* Wait for the form component to stabilize (which means that we are
happy with the state of the API and that enough people have played with
it and are happy with the features)
* Release 2.1 as soon as possible (because we already have quite a few
I thought that the second option was do-able by forking master and
reverting some PRs related to the form component (the ones that actually
break BC and are not stable yet because of some bugs or regressions --
surprisingly, we are not talking about many of them).
Many people think the contrary and so, I want to hear everybody's
opinion on this matter.
Let me reiterate the two possibilities here:
* Wait for the form component to stabilize: we can probably schedule 2.1
for August 2012. In the meantime, we should concentrate on the form
component and delay other big changes that can affect the stability of
* Release 2.1 as soon as possible.
Whatever we choose, I want to next Symfony 2 releases to have shorter
release cycles (a bit like what I do with Twig); and for that to happen,
we need to keep BC as much as possible so that people can upgrade to new
versions without any fear.
Sensio CEO - Symfony lead developer
sensiolabs.com | symfony.com | fabien.potencier.org
Tél: +33 1 40 99 80 80
|Re: [symfony-devs] Symfony 2.1 release||Jordi Boggiano||4/27/12 11:15 AM|
On 27.04.2012 20:09, Fabien Potencier wrote:I'm for waiting. 2.0 was a first step, let's make 2.1 the one breaking
release - because it's just not possible to get everything right the
first time. A shorter release cycle with BC sounds great after that.
@seldaek - http://nelm.io/jordi
|Re: [symfony-devs] Symfony 2.1 release||Julien Moulin||4/27/12 11:19 AM|
I think it's important to have stability, more than to release a new version. A new version rhymes with maturity, if we think that a part need more time, it is probably wiser to wait. We'll be even happier and our users too.
2012/4/27 Fabien Potencier <fabien.p...@symfony-project.com>
Julien Moulin - Chef de projet actif
Mobile : 06.33.43.47.54 - Fixe : 09.50.13.67.80 - Fax : 09.55.13.67.80
Auto-entreprise - Siret : 523 295 293 00022 - APE : 6201Z
|Re: [symfony-devs] Symfony 2.1 release||Mark Badolato||4/27/12 11:26 AM|
On Fri, Apr 27, 2012 at 11:09 AM, Fabien Potencier <fabien.p...@symfony-project.com> wrote:
I'm for delaying 2.1 until it's ready.
|Re: [symfony-devs] Symfony 2.1 release||Greg Militello||4/27/12 11:33 AM|
Personally I would prefer more smaller releases as much as possible. It makes code migration that much easier. I remember the absolute pain it was to go from 1.0 to 1.1 (granted some of that was due to poor code development on my end) but that was a hard transition.
Now I also realize 2.0 is nothing like 1.0. That being said one BC break is always ideal over several generations of BC breaks. However it does not sound terrible to get ready for a 2.1 release without the form component changes.
I can go either way, and I definitely see benefits/drawbacks to both possibilities.
|Re: [symfony-devs] Symfony 2.1 release||Kris Wallsmith||4/27/12 11:35 AM|
I support reverting the form and validator BC breaks in the 2.1 branch and releasing sooner than later. It doesn’t make sense to delay release of all the goodness that is stable in 2.1 to give the form/validator work time to stabilize.
Releasing 2.1 now also gives the form/validator work more time so we can be sure we get it right and not have to break BC again.
|Re: [symfony-devs] Symfony 2.1 release||Johannes Schmitt||4/27/12 11:59 AM|
In theory, I would have been for feature freezing the 2.1 branch before starting the form refactoring and then doing it in master, but since this is not possible anymore, and bundles have adjusted to this already. I would prefer to wait a bit longer with the 2.1 release.
For the future, I think we should clearer communicate when we make a feature freeze and then split branches. So, that we can stabilize one branch for release while continuing the development in the master branch.
|Re: [symfony-devs] Symfony 2.1 release||Michał Piotrowski||4/27/12 12:00 PM|
> We need toTaking care about BC is very important, and I'm really happy that you
aim so high, but you can not assume that you want to break BC only
This is something that I asked a few months ago. Something like Linux
model - 3 month feature merge window and 3 month stabilization phase
would be cool.
> --Best regards,
|Re: [symfony-devs] Symfony 2.1 release||William Durand||4/27/12 12:02 PM|
We are waiting for almost a year, we can still wait 4 months to get a great release.
Let's delay the 2.1 to get more adopters, except if we can upgrade from 2.0 to 2.1 without any BC breaks but I'm pretty sure it's not possible.
|Re: [symfony-devs] Symfony 2.1 release||Pablo Godel||4/27/12 12:04 PM|
I would prefer to release 2.1 asap without the stable Form. If it has BC breaks, it does not matter if you break now or later. Delaying all the nice features that 2.1 has because of forms does not make sense. Keep in mind that not everybody uses Forms yet due to its unstable status.
|Re: [symfony-devs] Symfony 2.1 release||Jordan ALLIOT||4/27/12 12:42 PM|
I'm for waiting.
|Re: Symfony 2.1 release||Daniel A.Tiecher||4/27/12 12:43 PM|
I share Kris's opinion. We have already dragged this release a lot and then postponing it to August would mean that a truck load of new PRs would be opened against master, which in turn would need to:
a) be integrated in the 2.1 release and possibly hurt the stability of the codebase which could push the tentative date even further
b) be left alone until we release 2.1
Option a will go against the shorter release cycles Fabien expects Symfony2 to have and option b is definitively a bad choice to attract new contributors.
|Re: Symfony 2.1 release||Michel Salib||4/27/12 1:10 PM|
At first I wanted to delay 2.1 till august. But after reading Kris and Daniel answers, I think it is better to release now.
Releasing now is a way to start the short release cycle practice and attract new contributors.
Also I perfectly understand how it could be painful to revert commits from the master branch.
Fabien, you asked the question but did not say what you think about the subject. Can you give us your thoughts ?
|unk...@googlegroups.com||4/27/12 1:44 PM||<This message has been deleted.>|
|Re: Symfony 2.1 release||Florin Patan||4/27/12 2:09 PM|
At the moment the options are:
Since Symfony2 Framework is in fact
a bunch of Components tied together into a framework/repository and we have
Symfony2 Standard which actually makes those Components act as a MVC framework,
I see no reason not moving the Components to their own version/release cycle
and have Symfony2 Standard become the Symfony2.X version release for the whole
At least this is my understanding of how Components should act like and what Symfony2 Standard/Composer are/should be for and how I think people would be less scared by the wave of BC breaks in major releases.
|Re: [symfony-devs] Re: Symfony 2.1 release||Mark Badolato||4/27/12 2:23 PM|
On Fri, Apr 27, 2012 at 12:43 PM, Daniel A.Tiecher <dati...@gmail.com> wrote:I share Kris's opinion. We have already dragged this release a lot and then postponing it to August would mean that a truck load of new PRs would be opened against master, which in turn would need to:
A branch could be created RELEASE_2_1 which is feature-frozen and only for bug fixes and component stabilization towards the release. PR's for new features etc would continue to be contributed to master. When RELEASE_2_1 is ready, it gets tagged, release, and the work gets merged back down into master. Conflict resolutions, compatibility issues etc need to be resolved, but this is true of any scenario.
Bugs affecting (necessary for) the release should be part of the RELEASE_2_1 branch, but if they are sent as PRs to master, there's no reason that it couldn't be cherry-picked for RELEASE_2_1, which makes sense since it's a bug that affects the release.
Further along in the development cycle, when it's feature-freeze time (or other appropriate time) a RELEASE_2_2 branch would be created from master, then lather, rinse, repeat.
|Re: [symfony-devs] Re: Symfony 2.1 release||Klaus Silveira||4/27/12 2:58 PM|
I'm voting for waiting until 2.1 has the form component stable enough. We can organize more bug hunts or even test fests to get everything in place.
|Re: Symfony 2.1 release||Damon Jones||4/27/12 9:10 PM|
+1 for waiting for a 2.1 release
As tempting as it is to have 2.1 sooner and be able to take advantage of all the new features and enhancements, I'd rather wait for a stable 2.1 release which has the forms components and everything finalised.
Another couple of months of waiting aren't that significant, compared to the pain of reverting changes (for anyone using master, or developing bundles for it) to rush out a 2.1 release.
If that happens and 2.0 users upgrade to 2.1 then they potentially have even more changes to cope with (including breaking-BC changes) when 2.2 is released in July/August. To have 2 releases that close together with significant changes seems like it would be a definite pain point for many users.
I expect there will also be some confusion with having documentation which is up-to-date for each version.
|Re: [symfony-devs] Symfony 2.1 release||Thomas Lundquist||4/28/12 12:58 AM|
On Fri, Apr 27, 2012 at 08:09:50PM +0200, Fabien Potencier wrote:I vote for a proper 2.1 release with everything that's supposed to break as
one big chunk.
Aka: first option.
The way short release cycles work is with a pretty strict release manager.
Do we have someone like that? The manager would have to cope with people
nagging about just that little fix that saves the world and whales, aka
"Just say no".
With timed releases it's alot easier to be able to say no, just point
at the time schedule and it should be understood.
But we still need one.
And tests, both compatibility and regression, loads.
|Re: Symfony 2.1 release||Hugo HAMON||4/28/12 1:59 AM|
I'm for releasing a 2.1 sooner without the Form component update.
There are plenty of small nice features in 2.1 like the new WDT and
some bug fixes. Without the form component commits it will be very
easy to upgrade from 2.0 to 2.1. If I'm not mistaken, the 2.1 code
base is quite compatible with the 2.0 branch. So go for a release. If
most people migrate to 2.1 now, it will be easier for them to migrate
from 2.1 to 2.2 as mostly the Form component will change. Same for
community bundles. Bundles can be migrated to 2.1 easily and we will
have extra time to migrate them to 2.2 then.
|Re: Symfony 2.1 release||Oleg Stepura||4/28/12 2:29 AM|
+1 for waiting
It's better to have more changes in a next version even when it'll break backward compatibility
|Re: Symfony 2.1 release||canni||4/28/12 3:10 AM|
I think we can have best of both worlds, linux kernel for years had similar this technique, why not to follow guidelines like this:
1) Even minor numbers are considered stable (like 2.0, 2.2)
2) Odd minor versions are "community" versions
3) Every time when mainline "even" aka stable version come up, community starts its job and post version like 2.1
4) when things from 2.1 are getting stable, over a time, they can be merged into 2.2-beta/alpha whatever...
5) 2.0 stable continues to evolve without BC breaks and with fixes, 2.1 may or may not merge them into community
With this guidelines anybody can be satisfied, people may play with beading edge version, and anyone can go for Even version, and wait till next stable version, to minor numbers achead
|Re: [symfony-devs] Re: Symfony 2.1 release||Michał Piotrowski||4/28/12 3:46 AM|
This doesn't makes sense for Symfony. Linux doesn't use this model since 2003.
|Re: [symfony-devs] Symfony 2.1 release||Matt Robinson||4/28/12 4:30 AM|
Some (I think) pragmatic possibilities:
1. If it's possible to run the 2.0 Form component in 2.1 (less work than backing out non-BC changes to 2.1, right?), then bundle the new Form component separately with a longer term view of making the new version the default. This is like the transition that Symfony 1.x went through from Propel to Doctrine as default. People still happily use both, and the 2.0 Form component still needs to be maintained anyway, since 2.0 is a long-term-stable release.
2. If all the other changes are BC, backport them into 2.0 and release asap. Then the 2.1 release only has the BC-breaks like Forms. We shouldn't focus too much on what the version number is, it's the compatibility that's important.
Long ago, I remember Fabien mentioned that he hoped there'd be multiple editions of Symfony2, and that the Standard Edition is just one of them. Perhaps we could resurrect that idea and have a "Standard edition" (with guaranteed BC) and an "Edge edition" (which doesn't mind breaking BC).
In a way we already do this by having 2.0 as a long-term-stable release, but to do it properly it should get stable, backward compatible changes backported from the development branch. Otherwise it'll become outdated, and people who want compatibility and stability will have to sacrifice an ever-increasing amount of features and improvements as 2.1, 2.2 and 2.3 are released. This also helps to prevent the community drifting apart into two groups: those who have to use the Stable 2.0 branch, and those who can risk BC moving on to 2.1, 2.2 etc.
|Re: [symfony-devs] Symfony 2.1 release||William Durand||4/28/12 7:03 AM|
Are you sure?
There is absolutely no good reason to release a 2.1 version as soon as possible if 2.1 is not fully BC with 2.0. In that case, it could be a nice strategy to kill 2.0.
Otherwise, there is no reason to release a version with "broken forms" (up to you to find a better definition). People who are still using 2.0 won't upgrade if they are not able to upgrade safely.
By the way, the Pull Request to revert recent changes on the Form component reverts improvements (which is ok to avoid BC breaks) but also fixes! So what? Why would you want to release a 2.1 version now, and not just to wait four months? Marketing strategy?
2012/4/28 Matt Robinson <ma...@lazycat.org>
|Re: [symfony-devs] Symfony 2.1 release||Guilherme Blanco||4/28/12 9:19 AM|
I'd vote for delaying 2.1 too until forms update.
My situation is pretty much the same as many other developers here.
Writing a massive application on 2.0 and considering a migration to
2.1. I tried 4 times to migrate and not only forms, but many other
places have crashed.
I can tell you changes in Session, default locale, Security (I have my
own implementation at the top of it, which means not using
FOSUserBundle), and many other dependencies that haven't yet moved to
I'd better wait until have Forms stable and then migrate, specially
because the effort to me now would be big and considering another one
around August is a no-go.
On Sat, Apr 28, 2012 at 10:03 AM, William Durand
>> Without the form component commits it will be very
>> easy to upgrade from 2.0 to 2.1. If I'm not mistaken, the 2.1 code
>> base is quite compatible with the 2.0 branch.
> Are you sure?
> There is absolutely no good reason to release a 2.1 version as soon as
> possible if 2.1 is not fully BC with 2.0. In that case, it could be a nice
> strategy to kill 2.0.
> Otherwise, there is no reason to release a version with "broken forms" (up
> to you to find a better definition). People who are still using 2.0 won't
> upgrade if they are not able to upgrade safely.
> By the way, the Pull Request to revert recent changes on the Form component
> reverts improvements (which is ok to avoid BC breaks) but also fixes! So
> what? Why would you want to release a 2.1 version now, and not just to wait
> four months? Marketing strategy?
> 2012/4/28 Matt Robinson <ma...@lazycat.org>
>> Some (I think) pragmatic possibilities:
>> 1. If it's possible to run the 2.0 Form component in 2.1 (less work than
>> backing out non-BC changes to 2.1, right?), then bundle the new Form
>> component separately with a longer term view of making the new version the
>> default. This is like the transition that Symfony 1.x went through from
>> Propel to Doctrine as default. People still happily use both, and the 2.0
>> Form component still needs to be maintained anyway, since 2.0 is a
>> long-term-stable release.
>> 2. If all the other changes are BC, backport them into 2.0 and release
>> asap. Then the 2.1 release only has the BC-breaks like Forms. We shouldn't
>> focus too much on what the version number is, it's the compatibility that's
>> Long ago, I remember Fabien mentioned that he hoped there'd be multiple
>> editions of Symfony2, and that the Standard Edition is just one of them.
>> Perhaps we could resurrect that idea and have a "Standard edition" (with
>> guaranteed BC) and an "Edge edition" (which doesn't mind breaking BC).
>> In a way we already do this by having 2.0 as a long-term-stable release,
>> but to do it properly it should get stable, backward compatible changes
>> backported from the development branch. Otherwise it'll become outdated, and
>> people who want compatibility and stability will have to sacrifice an
>> ever-increasing amount of features and improvements as 2.1, 2.2 and 2.3 are
>> released. This also helps to prevent the community drifting apart into two
>> groups: those who have to use the Stable 2.0 branch, and those who can risk
>> BC moving on to 2.1, 2.2 etc.
>> On 27 Apr 2012, at 19:09, Fabien Potencier wrote:
>> > Hi all,
>> > The Symfony 2.1 release was expected to be published some time ago and
>> > we struggle with it for two main reasons:
>> > * The number of contributions we have every single day. That's great but
>> > it means that it is never a good time to release because of this last minute
>> > great change that we want to merge first;
>> > * The recent BC breaks in the form/validator components.
>> > But basically, we cannot release 2.1 because of the second point. We
>> > need to be sure that we only break BC for forms only once. So, we have two
>> > options:
>> > * Wait for the form component to stabilize (which means that we are
>> > happy with the state of the API and that enough people have played with it
>> > and are happy with the features)
>> > * Release 2.1 as soon as possible (because we already have quite a few
>> > nice enhancements).
>> > I thought that the second option was do-able by forking master and
>> > reverting some PRs related to the form component (the ones that actually
>> > break BC and are not stable yet because of some bugs or regressions --
>> > surprisingly, we are not talking about many of them).
>> > Many people think the contrary and so, I want to hear everybody's
>> > opinion on this matter.
>> > Let me reiterate the two possibilities here:
>> > * Wait for the form component to stabilize: we can probably schedule 2.1
>> > for August 2012. In the meantime, we should concentrate on the form
>> > component and delay other big changes that can affect the stability of the
>> > release.
>> > * Release 2.1 as soon as possible.
>> > Whatever we choose, I want to next Symfony 2 releases to have shorter
>> > release cycles (a bit like what I do with Twig); and for that to happen, we
>> > need to keep BC as much as possible so that people can upgrade to new
>> > versions without any fear.
>> > Fabien
>> > --
>> > Fabien Potencier
>> > Sensio CEO - Symfony lead developer
>> > sensiolabs.com | symfony.com | fabien.potencier.org
>> > Tél: +33 1 40 99 80 80
>> > --
>> > 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 symfon...@googlegroups.com
>> > To unsubscribe from this group, send email to
>> > symfony-devs...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/symfony-devs?hl=en
>> 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 symfon...@googlegroups.com
>> To unsubscribe from this group, send email to
>> For more options, visit this group at
> 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 symfon...@googlegroups.com
> To unsubscribe from this group, send email to
> For more options, visit this group at
Toronto - ON/Canada
|Re: [symfony-devs] Symfony 2.1 release||Joe Cai||4/28/12 11:40 PM|
+1 for a release ASAP. Most of the time technology decisions are
simply trade-offs. In this case I think it is more important to kick
2.1 out of door and get more community feedback. August is still
months away. There would be other PRs that want to get merged.It's not
worth delaying everything just for form/validator. After all, we all
agree that a shorter release cycle would be better. Why not do it now?
|RE: [symfony-devs] Symfony 2.1 release||Michael C (UKB)||4/29/12 12:54 AM|
I'm +1 for waiting for it to stabilise so BC will only break once. But I'd
think still make a 2.1 branch so that new features go into master (2.2) and
only fixes (and form/validator changes) will be merged into the 2.1 branch.
|Re: [symfony-devs] Symfony 2.1 release||keymaster||4/29/12 2:46 AM|
I think the answer depends on two things:
1. If it is easy to upgrade from 2.0 to 2.1 after reverting the BC breaking form stuff - then yah, it's a no brainer, release 2.1 now and everyone gets the goodness. What's the question?
2. On the other hand, if it is already difficult to upgrade from 2.0 to 2.1, I'd say only put people through the pain once, in July/Aug (with - and this is THE most important thing - very detailed and clear documentation on how to do the upgrade, and maybe even some automated tools to help, where possible :-))
Your call, Fabien. :-)
|Re: [symfony-devs] Symfony 2.1 release||weaverryan||4/29/12 10:17 AM|
I would like to wait.
There are 2 things that make an upgrade a headache:
1) BC breaks
2) Lack of documentation, examples, not-yet-updated 3rd-party bundles, and unpolished states for new features.
I think that the world (via docs, blog posts, bundles, those bundle's READMEs) is still largely catching up with 2.1. The RC stage will help with this, but I think that #2 will be less of a big deal if we wait.
Composer is one big area of concern for me. If we release 2.1 in the next few weeks, there may not be any BC breaks, but Composer will represent a major change and challenge. I work with several individuals who have already upgraded to Composer, and it's been a painful process for each. Composer is great, but I'd like to give some more time for everyone to catch up on it.
US Office Head & Trainer - KnpLabs - Nashville, TN
|Re: [symfony-devs] Symfony 2.1 release||Drak||4/29/12 2:19 PM|
I would prefer to wait until the Forms code is more stable - it's such an important component it's better to get this done right - that will necessitate some waiting to let it mature as people use it and iron out the remaining issues. Another 4 months is not so long to wait imo. Good software takes time to mature, just like good wine.
On 27 April 2012 23:54, Fabien Potencier <fabien.p...@symfony-project.com> wrote:
|Re: Symfony 2.1 release||Pirate Bob||4/29/12 6:49 PM|
I can't help but feel that 2.1 is what 2.0 should have been, so I think it's worth waiting and making it the best it can be.
|Re: Symfony 2.1 release||Pirate Bob||4/29/12 6:54 PM|
Can't help but feel that 2.1 is what 2.0 should have been, so I think waiting to make it the best it can be is a good idea.
|Re: [symfony-devs] Symfony 2.1 release||Eriksen Costa||4/29/12 10:52 PM|
I'm with the people that prefers to wait. And as Ryan noted, this will
helps the ecosystem to sync with 2.1. And shorter release cycles with
BC sounds good too. Will it be timeboxed?
|Re: Symfony 2.1 release||Rootie||4/30/12 12:23 AM|
+1 for releasing now
By the time the Form part is stabilized there eventually will be another component which has a super new feature (that eventually breaks BC) -> then we are at the same situation as we are now. Do we wait for 4 months now and then for another 4 months again, and again...?
Also there are already some BC breaks. And if we wait the probaly will come even more BC changes besides the Form component. The more breaks there are the harder it gets to update from one version to the next. And it is a unpleasant work to go from one error (caused by a BC break) to the next, to the next...
If there are fewer breaks people are more willing to upgrade and won't get too much bugged after the upgrade.
On the other side, releasing now, will also give the people the choice if they want to wait until Symfony 2.2 or just upgrade to 2.1.
Also releasing now (and in shorter cycles in general) lets the project look more active. Not everyone looks at the commits in the repository. The releases are what counts for end users.
|Re: [symfony-devs] Symfony 2.1 release||David Allix||4/30/12 12:57 AM|
I'm for a first 2.1asap without massive promotion, and a 2.2 in july/august as you think about.
Lots of bundle are now mainly compatible for 2.1, as doctrine extension, and stay with 2.0 is become blocking for starting new project.
|Re: [symfony-devs] Symfony 2.1 release||keymaster||4/30/12 1:42 AM|
The big issue with waiting is it just increases the risk and expectations on the eventual 2.1 as it becomes heavier and heavier.
Documentation will fall farther behind as new stuff is committed, upgrades will become more complicated, more features will need to be assimilated, and the number of tasks to organize and make the release process successful will grow too large, which in itself is a huge risk.
We will all be much better off if we release the stuff we have working now, even if it means reverting some BC breaking stuff, as Fabien and a number of other core developers have recommended.
This will create a necessary checkpoint where people are up to date with things again. It will be easier to move forward from there, with less risk to the subsequent releases.
|Re: Symfony 2.1 release||Rootie||4/30/12 3:05 AM|
+1 for releasing now
maybe by the time when the Form changes are finished/stabilized there will be another component which also has a super cool new feature which should go into the release. (And it also evntually breaks BC). Then we are in the same situation as now. So should we wait 4 months now for the Form Component, then another 4 months for Component x, and so on?
Also Symfony already has some BC breaks. And even after the next release there will surely be more BC breaks. The more breaks there are the harder it will get to upgrade. To fix a few code/config parts is OK. But as it gets more it becomes a frustrating work which is not good for Symfony and also maybe prevent users from upgrading.
On the other side if we are releasing now the user can choose for himself if he wants to upgrade now and get all the new features and fix BC breaks step by step or if he wants to wait longer and do all the hard work for fixing all the BC breaks at once.
Also if we release now (and in shorter cycles in general) for the end user the project seems more active. For the end user the releases are what counts and not the commits to the repository.
|Re: [symfony-devs] Symfony 2.1 release||Thomas Lundquist||4/30/12 3:09 AM|
On Mon, Apr 30, 2012 at 01:42:04AM -0700, keymaster wrote:Will we then remove *all* BC breaks? If yes there is no reason not to
release a 2.1 but I'm pretty sure this is not the case.
So again: Do not start the trend of BC breaks for every minor release,
this *will* annoy, frustrate and scare the users.
|Re: [symfony-devs] Symfony 2.1 release||Christophe COEVOET||4/30/12 3:19 AM|
Le 30/04/2012 12:09, Thomas Lundquist a �crit :
We will not remove all BC breaks as not all of them are related to
forms. There is no reason to revert the refactoring of the Session for
instance as the new architecture is better and users starting to code
with Symfony 2.1 should benefit from the new (fixed) architecture
instead of using the old one and having to rewrite their code.
Christophe | Stof
|Re: [symfony-devs] Symfony 2.1 release||Thomas Lundquist||4/30/12 3:29 AM|
On Mon, Apr 30, 2012 at 12:19:46PM +0200, Christophe COEVOET wrote:So, simple questions: When can the users expect a Symfony release they
can use for a few years without minor or major rewrites because of BC breaks?
Right now, and with the story so far, both symfony 1 and 2, the answer
seems to be "never".
And *that* should be communicated to users so they can do a better qualified
choice. Honesty is always a good thing.
|Re: [symfony-devs] Symfony 2.1 release||Matt Robinson||4/30/12 4:20 AM|
On 30 Apr 2012, at 11:29, Thomas Lundquist 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?)
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. Look at RHEL/CentOS or Ubuntu LTS - they're supported for 3-5 years, and in that time usually get only bug-fixes, not new features.
|Re: [symfony-devs] Symfony 2.1 release||Thomas Lundquist||4/30/12 4:48 AM|
On Mon, Apr 30, 2012 at 12:20:42PM +0100, Matt Robinson wrote: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:
Btw, an expiration of november 2012 for symfony 1.4 is way too early for
it to be called *long term* support.
In my view, three years after the next major release as an LTS is a minimum.
Others would say five years all in all.
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
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.
|Re: [symfony-devs] Symfony 2.1 release||Christophe COEVOET||4/30/12 4:55 AM|
Le 30/04/2012 13:48, Thomas Lundquist a �crit :
> On Mon, Apr 30, 2012 at 12:20:42PM +0100, Matt Robinson wrote:2.0 has never been announced as being an LTS. The blog post announcing
the release even says that some components (including Form) are not
considered as being in a stable state yet.
Christophe | Stof
|Re: [symfony-devs] Symfony 2.1 release||Matt Robinson||4/30/12 5:17 AM|
On 30 Apr 2012, at 12:48, Thomas Lundquist wrote:Right, it -had- 3 years of support, which are now long over. Sorry if I didn't make that clear.
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.
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.
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.
|Re: [symfony-devs] Symfony 2.1 release||Thomas Lundquist||4/30/12 6:07 AM|
On Mon, Apr 30, 2012 at 01:17:58PM +0100, Matt Robinson wrote: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".
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.
And picking bundles to use are even harder, you never really know which will
be maintained upwards to the LTS which then will make self-maintaining
third party bundles manageable.
But no one will take responsibility for it and that should worry
And maybe scare them off from Symfony2 where the story seems to be the same.
Not entirely correct, I am applying my view on how it *should* be while
knowing how it is.
And chasing the changes.
|Re: [symfony-devs] Symfony 2.1 release||Fabien Potencier||4/30/12 6:49 AM|
On 4/30/12 3:07 PM, Thomas Lundquist wrote:As far as I know, supporting a web framework for 3 years is not
something that is proposed by many frameworks out there.
Anyway, as I said before, we will probably continue to support 1.4 after
2012, mostly for PHP forward compatibility and security issues. I will
write a blog post about this soon.
Sensio does. If you are concerned about stability for a very long period
of time, and if you are building a million dollar website with Symfony,
Sensio can probably help you.
|Re: [symfony-devs] Symfony 2.1 release||Matt Robinson||4/30/12 6:57 AM|
On 30 Apr 2012, at 14:07, Thomas Lundquist wrote:
>> Why? It's 3 years: November 2009 to November 2012. Do you mean that there'sSure, 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.
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.
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.
|Re: [symfony-devs] Symfony 2.1 release||Johannes Schmitt||4/30/12 7:03 AM|
As a side-note, to my knowledge Spring Framework provides 3 months (!) of bug fixes for their community edition. Otherwise, you have to buy commercial support.
So, 3 years without paying for it, is quite generous to say the least.
|Re: [symfony-devs] Symfony 2.1 release||Thomas Lundquist||4/30/12 7:08 AM|
On Mon, Apr 30, 2012 at 03:49:12PM +0200, Fabien Potencier wrote:Which is not a very good argument for using them.
Good, I am sure people will be very happy about that.
Absolutely a good point and argument.
|Re: [symfony-devs] Symfony 2.1 release||Florin Patan||4/30/12 7:36 AM|
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.
|Re: [symfony-devs] Symfony 2.1 release||Thomas Lundquist||4/30/12 7:39 AM|
On Mon, Apr 30, 2012 at 02:57:39PM +0100, Matt Robinson wrote:True (as also stated to Fabien).
Which is my point also.
From building a 2.0 site today to the LTS wnehever that comes around.
If the version you use is EOL, will the fixes be around?
Since I am in some of the same business, there are willingness to pay
when we see the need to pay.
True as well.
But the more time with the same API, the more development and stuff will
be available for more people and it makes it easier to share out your
own stuff without ending up with too much maintenance.
A main reason for picking a framework is the vast ecosystem around it and
the easier it is to use and be a part of that ecoststem, the better it is.
Symfony is the Qt of web frameworks, look at it as that and it changes a bit.
By picking 1.4 now you also deny yourself the possibility to use stuff
our from the vild. That's OK for us developers earning money from
making this but it's not always good for the customer.
A web framework does not have to be used "on the web" and there are web based
systems made in the nineties still in daily use.
And they even work.
|Re: [symfony-devs] Symfony 2.1 release||Thomas Lundquist||4/30/12 7:46 AM|
On Mon, Apr 30, 2012 at 07:36:21AM -0700, Florin Patan wrote:Good to hear and it makes me want to start using master with the project
I am about to start now. I'll prolly end up with that if we choose to go for
The other Sf2 projects I have running already is of course 2.0 and
I have a slight feeling I shouldn't spend too much time on forms
if I dont want to be stuck there.
Seems like this option is the one with the most votes.
|Re: [symfony-devs] Symfony 2.1 release||Bernhard Schussek||4/30/12 8:49 AM|
2012/4/30 Thomas Lundquist <thom...@redpill-linpro.com>:
> The other Sf2 projects I have running already is of course 2.0 andMany people here comment about the BC breaks in the Form component as
if they needed to rewrite their complete application with 2.1. This
will not be the case.
To put this into perspective, you have to divide the BC breaks into
1. Breaks that affect a majority of users and will be hard to fix
2. Breaks that affect a majority of users and will be easy to fix
3. Breaks that affect a minority of users
Breaks in category 1 should worry you. But most - if not all - breaks
in the Form component belong to either 2 or 3. So, this should really
not be the end of the world, no matter if we release 2.1 now or later.
|Re: Symfony 2.1 release||Jordan Stout||4/30/12 10:24 AM|
I'm +1 on waiting.
The form component is really one of the most used features IMO. Granted a lot of other changes have been made, I'd feel a true benefit in upgrading releases if the form component was more powerful. Currently, one of my live apps is somewhat at a halt due to the terrible prototype and collections within collections... Evidentially it's fixed now (although I haven't played with it yet). All in one, I'd much rather wait as all users will benefit more and feel more comfortable in a stable form release.
|Re: [symfony-devs] Re: Symfony 2.1 release||Bernhard Schussek||4/30/12 10:39 AM|
@Jordan: BTW you can help a lot to improve stability by testing your
application against master and verifying whether your problems are
fixed now and by reporting issues otherwise. We strongly rely on that.
2012/4/30 Jordan Stout <jorda...@gmail.com>:
|Re: [symfony-devs] Symfony 2.1 release||Greg Militello||4/30/12 10:43 AM|
I don't mind the BC breaks as long as they are well documented, my only concern is that we keep releases coming. Changes in 2.1 are great, and needed (imo) with or with out the new form logic. Personally as much as I want the new form stuff, I want other code more. In addition it is just a release. Yes it implies maturity (which 2.x will gain either way).
I am for releasing 2.1 asap. Planning on a three month window gives time for form to get wrapped up, tested and completed. Delaying will does not really help us aside from a revision number. And what happens is for some reason form is not 100% ready in 3 months, do we wait more? (I don't want to sound like I don't think Form will be complete, but things happen in life and not all things can be foreseen).
As for trying to not break BC multiple times, it is an admirable goal. But not always required. I expect some upgrade issues on major revisions. I don't like the upgrade issues, but it happens.
On Apr 30, 2012, at 11:49 AM, Bernhard Schussek wrot
|Re: [symfony-devs] Symfony 2.1 release||Julien DIDIER||4/30/12 2:46 PM|
Symfony2.0 has been released since less than a year.
I'm developing a new SOA appliance for my customer.
For some business logics, we are fetching 2.0.x.
But we have some limitations from the 2.0, that could be fixed by the 2.1.
It's like a trap, for developers, and for contributors.
I think, developers could need this version quickly as possible for more beautiful lines of code.
|Re: [symfony-devs] Symfony 2.1 release||Florin Patan||4/30/12 2:54 PM|
Sorry I don't get this approach?
If 2.1 will come in a week what would you do then?
Spend time to upgrade to master? Or go along in using master from start and if you bump into problems, create your patches and submit them to the framework so you can improve it?
I believe that's the problem with most of the people advocating for a fast release of 2.1.
Nobody is looking at the opened issues/PRs to see if something they are going to use is even flagged by a PR/issue so that they can take the decision to use master or not.
Also, whenever someone using the framework bumps into a problem at least an issue should be risen into GitHub so that other people contributing are aware of it/fix it if you don't have time to fix it, which I doubt since you need to further with the project, right?
|Re: [symfony-devs] Symfony 2.1 release||Marco Roello||4/30/12 3:03 PM|
I would like to introduce a (personal) problem that I encountered in the development of applications with symfony.
My feeling when I waited for the "big jump" to version 2.0, was that of a framework that among the various goals, had to transparently handle version management. One of the major management problems at the end of the application has been (at least for me) just the upgrade procedure.
"Everything is a Bundle": Symfony is a collection of bundles ....
If we explore knpbundles.com, the downloads of the most important bundles already points to 2.1, creating confusion about who develops on the stable version instead.
Personally, I would opt to leave the updates that contain important BC alone, in the sense that the programmer, in the specific update, should focus mainly on the impact of the BC side effects and not on changes of other behaviors.
|Re: [symfony-devs] Re: Symfony 2.1 release||chesteroni||4/30/12 4:11 PM|
On Friday, April 27, 2012 11:23:59 PM UTC+2, Mark Badolato wrote:
+1 for me
create tag, delay release until form will stabilise and do not merge new features from the middle of June.
|Re: [symfony-devs] Re: Symfony 2.1 release||Dattaya||4/30/12 10:53 PM|
i like this approach - release 2.1 now with:
* fixed bugs
* new features
* small bc breaks that affect a minority of users and easy to fix
so symfony2 users would upgrade their projects (and get new nice features) nearly without any effort - all or most of the bundles should work well with such new release.
|Re: [symfony-devs] Symfony 2.1 release||Lukas Kahwe Smith||5/2/12 1:04 AM|
So first up: yes we dropped the ball. Symfony 2.1 should have been released 4-5 months ago. So we screwed up. But stuff like this happens. Overall we are in a luxurious situation that we have such a huge stream of contributions that it poses a challenge. Now we need to deal with this screw up and also ensure we prevent this from happening again.
I have a bit of experience as the release manager of PHP 5.3 that its impossibly hard to try and wait for big chunks of code to mature in a healthy project with lots of other contributions. Everybody thinks their little change is a no risk must have. But everything that gets added does take time to review, has the risk of hidden surprises and in the end also needs to be documented.
At the same time there is no guarantee when exactly those big chunks of code will be ready to be shipped. Its good that Victor is helping Bernhard but even if everyone would now help on the form/validation component, that would probably not speed things up much. Everybody should however make sure to provide timely feedback to their progress.
But at any rate, any of these numbers people have mentioned are ok to wait for the form/validation component to mature are crystal ball estimates. 2, 3, 4 months, august .. its all just educated guesses.
Furthermore I dont think that breaking BC is binary. There are a lot of grey areas in between. We have a ton of really useful things in master already.
Finally the key goal here is that we want to get to an LTS release. I am not so sure that if we wait until August for 2.1 that we will have the confidence to release it as an LTS. So imho it makes more sense to come out with a 2.1 ASAP and then set us a timeline and feature set to target for 2.2 as an LTS. IMHO the RC phase should be planned for September/Oktober/November. Aka we feature freeze in September and then give us 2 months to release. But as noted above, there are never guarantees.
Lukas Kahwe Smith
|Re: [symfony-devs] Symfony 2.1 release||keymaster||5/2/12 4:49 AM|
+1 for creating a 2.1 branch, freezing new features, releasing it as RC.
Bug fixes only thereafter until stable.
New development carries on in Master.
Isn't this the "normal" way things should work anyways?
|Re: Symfony 2.1 release||adil adil||4/28/12 9:41 AM|
I'm voting for waiting until 2.1 has the form component stable enough.
|Re: Symfony 2.1 release||Patrick Landolt||5/3/12 12:32 AM|
I would go for releasing soon too. If the BC Breaks are documented well there is abolutely NO Problem for upgrading.
|Re: [symfony-devs] Symfony 2.1 release||Christophe COEVOET||5/3/12 12:48 AM|
Le 01/05/2012 00:03, Marco Roello a �crit :
> I would like to introduce a (personal) problem that I encountered inThis is simply a flaw in knpbundles: it displays only the Symfony
version required by the master branch of the bundle. But this does not
mean that other versions of the bundle cannot be compatible with Symfony
2.0.x. Many bundles out there are maintaining 2 branches, one for 2.0.x
and the other for 2.1
Christophe | Stof
|Re: [symfony-devs] Symfony 2.1 release||jaimesuez||5/3/12 8:23 AM|
+1 to 2.1 asap and 2.2 LTS
|Re: [symfony-devs] Symfony 2.1 release||Marco Roello||5/3/12 1:23 PM|
It is exactly what I was meaning.
I'm talking from a framework consumer perspective.
It seems that the knpbundles.com (the largest) community is trying to stay updated with the master branch, while (obviously) symfony stays on the stable realease.
And this makes confusion.
Symfony 2 is quite stable, meanwhile 2.1 seems a major update, with a lot of changes in many components.
We should always remember one the main purpose (it is my point of view) of a framework...allow the developer to do complex things in a simple manner.
So, if we have an update that can break something, in my opinion it must be isolated and well documented.
Il giorno giovedì 3 maggio 2012 09:48:41 UTC+2, Christophe COEVOET ha scritto:
Le 01/05/2012 00:03, Marco Roello a ï¿½crit :
|Re: [symfony-devs] Symfony 2.1 release||Christophe COEVOET||5/3/12 1:34 PM|
Le 03/05/2012 22:23, Marco Roello a écrit :The Knp team never advocated following Symfony master for bundles listed on knpbundles.com AFAIK. It is simply that the feature (requested by the community) has been implemented in the simplest way but we would obviously need a more complex one.It is exactly what I was meaning.
-- Christophe | Stof
|Re: Symfony 2.1 release||George K||5/3/12 11:43 PM|
I would vote for releasing the new version soon. Reason is that there are many differences between version 2.0 and 2.1.
If you are able to release the 2.1 version soon (with everything which is done till now and working) and the new features that are unstable
to be postponed for next revision 2.2.
Take this for an example: developing a SF2 site which should be long life supported should always follow the new official release (and not beta releases).
If 2.1 version is postponed every website built in the next 3 months for example will have to go through Framework update and 3rd party bundles update.
And there will be alot problems with 2.0 bundles updated to 2.1 bundles. ( or even worse, currently there are bundles for the 2.1 version will alot more options than the 2.0 onces)
Getting the 3rd party bundles working good for the new version could be tricky, could take time and alot of factors can affect.
What will happen according to me is that even if the Framework is perfectly done in 3 months and ready for the release of the new version,
bundles won't be... and getting 2.1 site to work could take up to 4 months or even more for large project with many 3rd party bundles.
Now what will happen if the new version is prepared and released soon. Every developer starting a new project will pick the new version.
Broken bundles will be fixed very soon after that. Everyone is happy.
Going from such 2.1 version to 2.2 version shouldn't be a pain and BC issues should be taken is a must needed evil to get the thing going in right direction :)
|Re: [symfony-devs] Symfony 2.1 release||omissis||5/4/12 9:13 AM|
I don't believe that any BC break that could possibly exist can be included in 2.1: most probably a few versions in the future will still have some, so I believe it's a bit too optimistic to hope for the next one to be the only one black sheep.
For this reason, I'm +1 for a 2.1 out as early as possible.
On Friday, April 27, 2012 8:15:41 PM UTC+2, Jordi Boggiano wrote:
On 27.04.2012 20:09, Fabien Potencier wrote:I'm for waiting. 2.0 was a first step, let's make 2.1 the one breaking
|Re: [symfony-devs] Symfony 2.1 release||Marco Roello||5/4/12 2:40 PM|
I did not want to attribute any fault to knpbundles.com. It is the most (maybe the only!) usefull sf 2.0 community.
But it is very important for everyone to understand that someone must drive the community on a specific direction.
|Re: Symfony 2.1 release||Peter||5/7/12 3:34 AM|
+1 for releasing now
As Bernhard said, most BC changes are not really a big deal. Sure it's better not to have them, but sometimes it cannot be avoided. Doing some minor adjustments in code and config files when upgrading is perfectly acceptable, when you weigh it against the benefits of having all the new features in 2.1.
Like many others, I'm anxiously waiting on 2.1. A trend I see more often these days, is that third party bundles are developed against master, and don't work with 2.0.x versions. This is not Symfony's fault off course, but it does indicate a problem: that we kind of have this situation where you have multiple codebases. Delaying 2.1 will increase the severity of this problem further. In my opinion this is far more annoying than doing some minor tweaks while upgrading.
Also, keep in mind that large software vendors do not shy from breaking BC when needed, to keep the innovation going. Look at Apple for instance.
|Re: [symfony-devs] Symfony 2.1 release||Michał Piotrowski||5/8/12 9:07 AM|
2012/4/27 Fabien Potencier <fabien.p...@symfony-project.com>:
> Whatever we choose,
After 11 days you know the opinion of some Symfony users and
developers. Did you make the decision?
|Re: Symfony 2.1 release||Klaus Silveira||5/23/12 11:02 AM|
So, any updates on the decision?
|Re: Symfony 2.1 release||Mario Alberto Alvarez Garcia||5/24/12 4:47 AM|
It seems like we are waiting for the Form component to be ready.
|Re: Symfony 2.1 release||chesteroni||5/29/12 2:56 AM|
On 24 Maj, 13:47, Mario Alberto Alvarez Garcia
> It seems like we are waiting for the Form component to be ready.Apparently... yes.
But it is so annoying - being questioned for and no conclusion
I think that we, as the developers community, deserve at least some
information about decisions which had been made.
|Re: [symfony-devs] Re: Symfony 2.1 release||Klaus Silveira||5/29/12 7:56 AM|
Be patient, chesteroni. Your tone doesn't fit the open-source initiative, so please, respect all the other developers involved.
|Re: [symfony-devs] Re: Symfony 2.1 release||Fabien Potencier||5/29/12 8:45 AM|
|Re: Symfony 2.1 release||chesteroni||5/29/12 10:18 AM|
|Re: Symfony 2.1 release||chesteroni||5/29/12 10:27 AM|
On 29 Maj, 16:56, Klaus Silveira <cont...@klaussilveira.com> wrote:Hm - I just don't think that my tone has anything to do with the open-
source and that my tone was inappropriate.
Wanting to know what the plans are and waiting over a month for a
decision is from my POV not a normal situation so I wrote that. How
else could I show my opinion about reality?
Anyway - if I'm not correct and somebody found my words offending or
inappropriate, then I'm sorry.
P.S. I don't want to be off-topic, so EOT.
|Re: [symfony-devs] Re: Symfony 2.1 release||Lukas Kahwe Smith||5/29/12 10:29 AM|
Yeah, I think the tone was ok. I totally understand that there was a bit of frustration mixed in there.
|Re: [symfony-devs] Re: Symfony 2.1 release||Fabien Potencier||5/29/12 12:19 PM|
|Re: [symfony-devs] Re: Symfony 2.1 release||ZermattChris||5/29/12 12:58 PM|
Thanks for the clear infos --
just starting my first real Symfony project, after years of following and tinkering around with it and finding it a real joy so far, many thanks to all for the quality hard work :-) .
-- ******************* Chris Banford Systems Manager ch...@swisspasses.com www.swisspasses.com Zermatt Swtizerland *******************
|Re: [symfony-devs] Re: Symfony 2.1 release||jaimesuez||6/11/12 6:38 AM|
Is there some change of plans about the realease?
Symfony live has concluded and still there is no the 2.1 beta
|Re: [symfony-devs] Re: Symfony 2.1 release||Mark Badolato||6/11/12 11:17 AM|
|Re: [symfony-devs] Re: Symfony 2.1 release||jaimesuez||6/11/12 11:32 AM|
I saw that, it's appears: "First 2.1 beta release after the hacking day at Symfony Live Paris".
|Re: [symfony-devs] Re: Symfony 2.1 release||Mario Alberto Alvarez Garcia||6/12/12 5:41 AM|
Yes, sure will be available soon.
|Re: [symfony-devs] Re: Symfony 2.1 release||Rob Loach||6/21/12 2:21 PM|
I just saw the 2.1.0-BETA1 tag appear in symfony/symfony!
This is great news and I'm really excited that we're getting closer to RCs. Any clue if the git-subtree projects will get the tag as well?
Thanks a lot!
Yes, sure will be available soon.
|How to debug doctrine queries with firephp?||Vladimir GT||6/19/12 5:05 AM|
Hi, just started with symfony.
How i can enable and integrate doctrine logger with symfony monolog?
|Re: [symfony-devs] Re: Symfony 2.1 release||Fabien Potencier||6/25/12 12:23 AM|
Tags for components are now available.
>> <http://symfony.com/blog/towards-symfony-2-1>> www.swisspasses.com <http://www.swisspasses.com>
> Zermatt Swtizerland> <http://symfony-project.com>
> To unsubscribe from this group, send email to> <mailto:symfony-devs%2Bunsubscribe@googlegroups.com>
> For more options, visit this group at> <http://symfony-project.com>
> To unsubscribe from this group, send email to> <mailto:symfony-devs%2Bunsubscribe@googlegroups.com>
|Re: [symfony-devs] How to debug doctrine queries with firephp?||Christophe COEVOET||6/25/12 12:38 AM|
Le 19/06/2012 14:05, rustyj4ck a �crit :
> Hi, just started with symfony.They are already logged using Monolog. But queries are logged at the
debug level so you need to change the level of the firephp handler to
see them (in the standard edition, it only accept messages starting at
the INFO level)
Christophe | Stof
|Re: Symfony 2.1 release||Joshua Nankin||7/5/12 6:19 PM|
Looking for an easy way to at least upgrade the file structure and dependencies for 2.1 from a 2.0 project. I realize I'll have to make the code changes in the changelog, but I really hope there's some command I can issue that will do a lot of the work for me.
I just came over from 1.4 to 2.0, and really am hoping future updates won't be like this.
On Friday, April 27, 2012 1:09:50 PM UTC-5, Fabien Potencier wrote:
|Re: Symfony 2.1 release||Mario Alberto Alvarez Garcia||7/6/12 5:31 AM|
That will be an awesome command! I also hope we can have in the future a command which develop my entire application....
Fun apart, there are things that must be done by hand.
|Re: [symfony-devs] Symfony 2.1 release||Matt Robinson||7/6/12 5:37 AM|
Symfony 1.1, 1.2 and 1.3 had fairly elaborate upgrade commands. It's not mad to suggest a 2.0 -> 2.1 command. Of course it might not be possible to upgrade some things like Forms automatically, but lots of the changes are straightforward and could be done programmatically.
|Re: [symfony-devs] Re: Symfony 2.1 release||Michał Piotrowski||7/6/12 5:40 AM|
2012/7/6 Mario Alberto Alvarez Garcia <nomack...@gmail.com>:
> That will be an awesome command! I also hope we can have in the future aSomething like
php app/console generate:app --type=auction_platform --like=ebay
would be awesome ;)
|Re: Symfony 2.1 release||Joshua Nankin||7/6/12 10:01 AM|
My experiences upgrading a 2.0 project to 2.1 are now here: