Symfony 2.2 Schedule Update

January 7, 2013 • Published by Fabien Potencier

First, and foremost, I would like to wish you, the wonderful Symfony community, the best for 2013. Enjoy your work, enjoy your family, enjoy your friends, ... enjoy using and contributing to Symfony!

Let's get back to business now. As part of the Symfony 2.2 release process, we will release the first beta of Symfony 2.2 tomorrow. As with any beta versions, the code is not stable yet; but having a package out of the door will give the opportunity for more people to test it out and report bugs and backward compatibility breaks on real-world projects.

This first beta also marks the end of the development period for Symfony 2.2; we are now entering the stabilization period for 2 months. It means that we won't accept any new features for Symfony 2.2 as of today (see below for some specific exceptions).

If you want to help us out, try to upgrade your Symfony 2.1 applications by following the UPGRADE instructions (and here are the ones for the Standard Edition). If something is not clear enough in the UPGRADE files, if there is something missing, or if your application does not work anymore after upgrading, consider posting your problem on the mailing-list, or submitting an issue; we have two months to polish everything so that upgrading when 2.2.0 stable comes out will be as easy as possible. Of course, keep in mind that running the upgraded application in production is not recommended.

What now? During the next two months, the community should focus on stabilizing Symfony 2.2: reporting bugs, reporting undocumented BC breaks, fixing bugs (have a look at our list of easy picks), updating the documentation (the official one but also all the numerous blog posts about Symfony2 out there), updating your bundles, writing about the new Symfony 2.2 features, ... Of course, you can work on new features, but we won't have a look at them before 2.2.0 final is released (if you want to submit a pull request, don't forget to tag it with `[2.3]` in the title).

Some of you are probably wondering why we are releasing a beta version and not a release candidate? That's because there are quite a few issues that we want to fix before (and they might have an impact on the current features):

adding support for the recently adopted PSR-3 logger interface;
re-evaluate some of the BC breaks we have done to avoid big impacts on your code (this is mostly for the Form component and also this pull request about sub-requests);
some pull requests that are ready but not merged yet (this will be done this week).

If everything works according to the plan, the first release candidate should be released by the end of January. Speaking of dates, here are some other important ones you need to keep in mind:

End of January 2013: End of maintenance for 2.0 (Symfony 2.0 being the first Symfony2 release enjoys a very long period of maintenance of 18 months);
End of February 2013: Release of 2.2 (and start of 2.3 development);
End of April 2013: End of maintenance for 2.1;
End of Mai 2013: Release of 2.3 (the first LTS).

Happy hacking!

Published in #Community

Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.

Comments

Tristan Bessoussa Certified said on Jan 7, 2013 at 15:51

I migrated http://www.seek-team.com with Symfony2.2, and I must say that I didn't get a single error yet due to the version bump (after i reviewed the code of course and changed few things to make it compliant).

Florin Patan said on Jan 7, 2013 at 15:51

Thanks for the info.

What about the performance issue for both the core and the other bundles from Symfony Standard? See: https://github.com/symfony/symfony-standard/issues/464

Thanks!

Christophe Coevoet said on Jan 7, 2013 at 16:21

Wouldn't it be more logical to schedule the end of maintenance of 2.0 and 2.1 just after a release instead of doing it 1 month before ? If an application is still using Symfony 2.0, it will have to upgrade to 2.1 first because 2.2 will not be stable yet, and will have to update to 2.2 again 2 or 3 months later because of the end of 2.1. Being able to go from 2.0 to 2.2 in one go seems more logical in this case.

Victor Berchet Certified said on Jan 7, 2013 at 17:40

What about defining some targets (ie in term of # of opened defects for the docs and the code) and a plan to get there (bug hunt days, priorities, ...) ?

Fabien Potencier Certified said on Jan 7, 2013 at 18:09

@Victor: How would you put a plan together without knowing who will be able to help? That sounds impossible to me. I'm ok to organize bug hunt days but from my experience, that does not help that much. What we need is a team of dedicated people helping fixing bugs on a regular basis. But I'm open to any suggestions.

Victor Berchet Certified said on Jan 7, 2013 at 19:36

@Fabien: "How would you put a plan together without knowing who will be able to help?" It actually sounds like the start of a plan to me.

Regarding the code, we could prioritize issues and ask volunteer devs to indicate which of those they plan to work on. We could also setup a team of volunteers to help on IRC. A first required step would to be enable filtering out 2.3 specific issues (prefix / tag).

Regarding the docs, the dev ml has a thread with pending questions. Then there could be a list of docs (Google docs / GH wiki) where reviewers would subscribe some chapters - in addition to something similar as the "process" described above.

I fear that most of the ~400 issues will remain opened if we don't come up with some plan.

Pierre Vanliefland said on Jan 8, 2013 at 00:54

Speaking for myself: I find it difficult to participate to Bug Hunt Days, as they don't occur very often and there's a low probability that I will be available that specific day. I think the "Easy Pick" tag in Github is the way to go for small-time contributors like me, but for now, the list is kind of small and most of its items are already being handled.

Hari K T said on Jan 8, 2013 at 07:55

Great work @Fabien. There is a typo Mai (May).

Lukas Kahwe Smith said on Jan 8, 2013 at 09:28

I think we should just continue to highlight "easy picks" but now additionally "must fix" tickets. also maybe we should encourage maintainers of components to offer "mentored tickets" or IRC feedback sessions for people wanting to work on tickets/docs in that component.

Björn Fromme Certified said on Jan 8, 2013 at 10:11

#10

@Lukas Kahwe Smith: "mentored tickets" are a great idea. Possible?

Florin Patan said on Jan 8, 2013 at 18:30

#11

@lsmith: Mentored tickets or tickets with some IRC assistance would actually be a great idea. I even if I'd have some time to contribute, without some help on some areas on how to do things, the Symfony way, it's quite hard.