+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 sign
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.
On Fri, Apr 27, 2012 at 6:23 PM, Mark Badolato wrote:
> On Fri, Apr 27, 2012 at 12:43 PM, Daniel A.Tiecher wrote:
>
>> I share Kris's opinion. We h
On Fri, Apr 27, 2012 at 12:43 PM, Daniel A.Tiecher 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) be integrated in the 2.1 r
At the moment the options are:
- wait for even longer before we can get 2.1 out because of a component
- release earlier and fix / break the component later on;
[TL;DR version] I would suggest for moving to a release 2.1 one once all
the fixes required for a stable Form component are done and
At least this is my understanding of how Components should act like and
what Symfony2 Standard/Composer are/should be for.
I see no reason why we couldn't have a release cycle for components like
the one Microsoft has for the Windows updates, every second Tuesday of
every month, in Microsoft's
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
t
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 coul
I'm for waiting.
Like the others, I'd prefer one bigger release with all the BC breaks and
then quicker releases that are BC.
We have already waited almost a year, a few months more can only be better
IMO.
Jordan ALLIOT
--
If you want to report a vulnerability issue on symfony, please send it to
Hi Ryan,
Yes I see your point, any it may be the behaviour that is intended, but I
don't think it's what we should really do as it doesn't make sense to me.
Look at it like this;
A user comes to the site, and through the remember me cookie, they are
authenticated based on their previous login.
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.
Regards,
Pablo
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.
William
Le 27 avr. 2012 à 20:35, Kris Wallsmith a écrit :
> I s
Hi,
2012/4/27 Fabien Potencier :
> Hi all,
>
[..]
> We need to
> be sure that we only break BC for forms only once.
Taking 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
once :)
>
> Whatever we choose, I want to n
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
Hi Chris!
I see your point, but I believe this is the intended behavior. I think (and
will be corrected if I'm wrong!) that unless you're IS_AUTHENTICATED_FULLY,
the firewall will give you a change to authenticate if you're denied
access. Since there's no difference between being denied access for
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 t
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 i
Hi guys!
It's not really an issue, just a difference in opinion about 18 months ago
:). Repository classes can go anywhere, so it's just about having a "best
practice" location. I think I probably suggested that they *might* go into
a Repository namespace via the docs and the generator supposed th
On Fri, Apr 27, 2012 at 11:09 AM, Fabien Potencier <
fabien.potenc...@symfony-project.com> wrote:
>
> 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
> co
Hi,
I want to use sphinx as a search engine in my site I just create it with
Symfony2, but I don't know how?
and how to use the bundle SphinxsearchBundle?
thank you in advance
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You recei
Does anyone have link for video recording?
On Friday, March 2, 2012 5:44:44 PM UTC+1, Daniel A.Tiecher wrote:
>
> Looking forward to that. Thanks for sharing the experience !
>
> Em quinta-feira, 1 de março de 2012 23h28min20s UTC-3, Eric Pickup
> escreveu:
>>
>> The Confoo guys hired a film cre
Hi all,
I have a bit of an oddity with the remember me implementation.
I've configured it based on the cookbook entry;
http://symfony.com/doc/current/cookbook/security/remember_me.html
And I have the cookie lifetime set to 20 days.
On login the cookie is set correctly, and if I let my session e
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
> Hi all,
>
> The Symfony 2.1 release was
I've never even realized it should be in Repository namespace/directory,
because I always generate repositories when generating entities, so I can
confirm this issue.
On Monday, April 23, 2012 6:46:08 PM UTC+2, Jeff Mott wrote:
>
> php app/console doctrine:generate:entity
>
> No arguments, so yo
On 27.04.2012 20:09, Fabien Potencier wrote:
> * 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.
I'm for waiting. 2.0
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
Hi,
2012/4/27 Mark Badolato :
> This is an interesting thread and I see very valid points from both sides of
> the debate.
>
> My opinion would be for not causing pain, regardless of how easy (easier) it
> is to manage with Git, and delay the 2.1 release. Call a feature freeze,
> and from then un
+1 for Mark's idea
take it easy guys
On Fri, Apr 27, 2012 at 12:37 PM, Mark Badolato wrote:
> This is an interesting thread and I see very valid points from both sides of
> the debate.
>
> My opinion would be for not causing pain, regardless of how easy (easier) it
> is to manage with Git, and d
This is an interesting thread and I see very valid points from both sides
of the debate.
My opinion would be for not causing pain, regardless of how easy (easier)
it is to manage with Git, and delay the 2.1 release. Call a feature
freeze, and from then until release, only allow bug fixes and the
It will be reverted only the BC breaks for the Form/Validator components,
but all others will remain. The main point is that left a while to
stabilize this components and they don't want to make BC breaks in both
versions (2.1 and 2.2).
El viernes, 27 de abril de 2012 09:55:52 UTC-4, Johannes
In principle, this sounds like a good plan. It will increase the burden on
bundle developers though, and this is probably something which can
communicated better in the future as other have pointed out already.
I'm wondering however which PRs are reverted. All PRs that break BC, or
just the ones t
On 27.04.2012, at 13:35, Thomas Lundquist wrote:
> On Fri, Apr 27, 2012 at 12:22:47PM +0200, Christophe COEVOET wrote:
>
>> If we keep the current code
>> for 2.1, it will be breaking BC twice as the current Form code is
>> not totally mature and needs some more changes (look at bernhard's
>> pe
I have read somewhere that LTS version will be 2.2 which will be released
on July/August of this year, as stated by @fabpot here:
https://github.com/symfony/symfony/pull/3378#issuecomment-5377420
There are many new features which are on master for quite a long time but
not on 2.0, so I guess th
Le 27/04/2012 14:01, keymaster a écrit :
Unless the current form stuff in Master will make life difficult
because it's not well thought out (in which case I agree it should be
reverted regardless of the pain), it might be appropriate to give
further consideration to either freeze new features
Unless the current form stuff in Master will make life difficult because
it's not well thought out (in which case I agree it should be reverted
regardless of the pain), it might be appropriate to give further
consideration to either freeze new features on Master and cut a RC as is,
or delay an
On Fri, Apr 27, 2012 at 12:22:47PM +0200, Christophe COEVOET wrote:
> The goal is to break BC in forms only once (between 2.1 and 2.2, by
> reverting the Form BC breaks in 2.1).
But the result is that BC breaks *twice* since I've understood that there
will be minor breaks between 2.0 and 2.1 eve
2012/4/27 Lukas Kahwe Smith :
>
> On Apr 27, 2012, at 12:06 , Michał Piotrowski wrote:
>
>> Hi,
>>
>> 2012/4/27 keymaster :
>>>
>>> If we go with 2.1 = (Master less Form/Validator BC breaks), won't that cause
>>> some confusion and destabilization in 3rd party land?
>>>
>>> Many 3rd party bundles h
Le 27/04/2012 12:16, Thomas Lundquist a écrit :
On Fri, Apr 27, 2012 at 02:39:26AM -0700, keymaster wrote:
If we go with 2.1 = (Master less Form/Validator BC breaks), won't that
cause some confusion and destabilization in 3rd party land?
Many 3rd party bundles have developed against Master and
2.1 has never been released, breaking support of bleeding edge bundles
is not of concern. Anyone using 2.1 for production should be expecting
pain.
Just like those using alpha versions had major form changes before the RCs.
+1 for revert
On Fri, Apr 27, 2012 at 20:11, Lukas Kahwe Smith wrote:
>
On Fri, Apr 27, 2012 at 02:39:26AM -0700, keymaster wrote:
>
> If we go with 2.1 = (Master less Form/Validator BC breaks), won't that
> cause some confusion and destabilization in 3rd party land?
>
> Many 3rd party bundles have developed against Master and work fine. They
> were slated to be th
On Apr 27, 2012, at 12:06 , Michał Piotrowski wrote:
> Hi,
>
> 2012/4/27 keymaster :
>>
>> If we go with 2.1 = (Master less Form/Validator BC breaks), won't that cause
>> some confusion and destabilization in 3rd party land?
>>
>> Many 3rd party bundles have developed against Master and work f
Hi,
2012/4/27 keymaster :
>
> If we go with 2.1 = (Master less Form/Validator BC breaks), won't that cause
> some confusion and destabilization in 3rd party land?
>
> Many 3rd party bundles have developed against Master and work fine. They
> were slated to be the "2.1 compatable" versions of their
If we go with 2.1 = (Master less Form/Validator BC breaks), won't that
cause some confusion and destabilization in 3rd party land?
Many 3rd party bundles have developed against Master and work fine. They
were slated to be the "2.1 compatable" versions of their bundles.
If we create a 2.1 branc
42 matches
Mail list logo
