On 9/17/12 2:32 AM, Lukas Kahwe Smith wrote:
* Coordinate our timeline with projects that we are using (Doctrine, Propel,
Monolog, Assetic, Twig, ...) but also with projects that are using/embedding
Symfony;
I think this is a very important point.
This way we do not need to do complex coordinations with releases, because the
general timeframe (maybe +- 3 weeks) is very clear. However we will also need
to setup some coordination for point releases (especially security stuff), but
also general bug fixing. However that is beyond of the scope of this proposal.
Timeline
--------
Six months should be fast enough for developers who want to work on the latest
and the greatest; but at the same time, companies might want more time to learn
and upgrade. The way to make everyone happy is to ensure an easy upgrade path
from one version to the next one. Take Twig as an example: I've been able to
release a new major version every month and a half since 1.0; that's very fast
and it has been possible because we've kept backward compatibility between all
major releases (and of course the scope of Twig is also smaller).
Just to expand on why this makes sense to me also: If you want to get a feature
into Symfony2, you can either get it into the next release which should be less
than 6 months away .. or if its too late in the release cycle (which means its
likely less than 3 months to the next release and its a big complex feature),
then you just have to wait less than 9 months to get it into the release after
that. So as a result nothing has really changed in how fast you can get a
feature in. The difference is that you can very quickly know the point in time
when the feature will make it in.
Six month releases mean that two releases fit in a year and so, everybody knows
when releases will be made without having to check on the website: for Symfony
it will be at the end of May and at the end of November of each year. That
brings predictability and visibility.
I would actually prefer April, October. May seems too close to the summer and November
too close to the "lets get some last features done on this years budget". Then
again one could say such a feature is the upgrade to the latest version.
Related logistical note: Drupal 8 is currently looking at code freeze 1
April next year. However, I think it's a fair bet that we'll want to
ship on 2.3 LTS, not on 2.2, which would go out of support well-before
Drupal 8 does. We'll need to coordinate between Fabien (and whoever
else is relevant) on the Symfony side and Dries/catch (the Drupal 8
leads) on the Drupal side to see how we want to handle that. Since
we'll likely be chasing master until then we may be able to just make an
exception to our code freeze for Symfony 2.3.
No action needed right now; I'm just flagging it as a discussion point.
I'll try looping in the Drupalers on my side. I cannot speak for the
release schedule of other Symfony-using projects.
--Larry Garfield
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
