Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

What keeps us from starting with 3.0? #11524

Closed
WouterJ opened this Issue · 16 comments
@WouterJ

Some history

  1. Back in July 2011, Symfony 2.0 released
  2. In October 2012, Fabien published a release process for symfony. This release process brought LTS releases to Symfony: Long bug and security support without having to upgrade your application with the risk of BC break
  3. In April 2013, Fabien introduced a new idea for Symfony: Stability over features
  4. In Januari 2014, Bernhard formalized this idea into the Symfony BC promise

The BC promise replaced LTS releases

With the BC promise, everyone can upgrade their applications to newer minor versions without having to worry about updating their code: It's BC! This means that it would no longer be neccesary to keep maintaining LTS releases, the whole 2.* version serie after 2.3 is one big LTS release.

3 Years of Symfony 2.*

3 days ago, we've all celebrated 3 years of Symfony 2.* (didn't you?). I believe it's time to move on and start working on Symfony 3.0. Why?

  • The 3.0 upgrade guide already contains lots of things
  • There are already enough features to fill 3.0 with lots of surprises: 3.0 milestone and others, which aren't milestoned yet, like #11457
  • The DX initiative has brought up even more things which can't be fixed in a BC manner
  • There is already a drive to bring new features to 2.* minor versions, which only caused confusion and angry devs (because of BC breaks). Those are for instance, the 3.0 directory structure and the Validation Visitor rewrite.
  • Starting now means releasing somewhere in 2015 or later, there is so much to do before we can get there!

What keeps us from starting with 3.0?

@fabpot
Owner

I've talked about this topic in some of my keynotes recently. And indeed, the work on 3.0 already started. As you mentioned, we have some promises and we cannot break those now. 2.6 is going to happen and 2.7 being the next LTS should probably happen as well. So, 3.0 could be released in place of 2.8, which is going to be in November 2015. I think that's a good target.

@mvrhov

Is it really 3 years. :omg. I started a first project with it when it was still early in development state. I do remember updating my code like crazy every few weeks.
Does that mean that the minimum supported php version will be 5.5? IMHO that would make sense as 5.4 will be unsupported from next march. (3 years since its release)

@WouterJ

Thank you for your quick response, @fabpot. I wasn't aware that you started preparing for 3.0. Maybe it's good to have some sort of public plan. E.g. discuss the big new features until March 2015, have a feature freeze in August 2015 and update all docs and bundles in August - November 2015?

Maybe we can start moving most of the new features after 2.6 to 3.0, so we can focus on make the 2.* branch 100% stable in 2.7 (releated too #11446 ).

And I think we also have to think about the LTS things for the 3.* branch. Would they make sense, now the complete major version must be BC, and thus is an LTS? Btw, I agree with you about releasing 2.7 LTS.

@lsmith77
Collaborator

For me also 2.7 was a very sure thing and so when asked I have always said that 2.8 might become 3.0. That being said, I do agree that a 3.0 needs longer planning than a 2.8 and I also think that given the maturity of 2.x and the list of things that cannot be done inside 2.x, that it makes sense to try and make a decision about 2.8 vs. 3.0 sooner rather than later as this might also enable us to work more on some forwards compatibility features that might make the move less painful.

@willdurand

it makes sense to try and make a decision about 2.8 vs. 3.0 sooner rather than later as this might also enable us to work more on some forwards compatibility features that might make the move less painful

:+1:

@andrerom

+1 from eZ, and PHP 5.5 sounds sensible as the baseline for 3.0 if it comes out next year.

@lsmith77
Collaborator

btw when we evaluate if its worth to go to 3.0, one thing to consider is our eco-system. eZ/Drupal are a good examples, they are just now getting ready to release their first version (entirely) based on Symfony. Laravel only recently had their first stable release. Even for fullstack there are still areas where we shold have more mature Bundles. of course some of what I am saying here depends on the upgrade path we can provide. I assume at this point it will be easier for people to move from 2.x to 3.x than it was from 1.x to 2.x.

@r1pp3rj4ck

@lsmith77 I think the update from 2.x to 3.0 will be like it was from 2.0 to 2.1. Of course I might be terribly wrong, I'm not an expert.

@iltar

I don't think you can compare 2.* to 3.0 with anything yet. It's not like 1.* to 2.0 where practically 100% is changed, nor is it as simple as going from 2.0 to 2.1 with only minor changes.

@pminnieur

I'd prefer a 3.0 over 2.8 -- :+1:

@andrerom

Well, speaking from experience I would advice the amount of changes to be kept low, nothing like 1.x to 2.x as this resets the maturity of the whole ecosystem as all bundles needs adjustments and so on. But @fabpot has blogged/talked about what he had in mind in the past, and it made sense (something like directory structure improvements, and tackle a few larger design issues to improve developer experience / rapidness, and of course add native wap support :P ).

@lmammino

I don't think you can compare 2.* to 3.0 with anything yet. It's not like 1.* to 2.0 where practically 100% is changed, nor is it as simple as going from 2.0 to 2.1 with only minor changes.

I do agree with @iltar,
Switching from 2.* to 3.0 will not probably be as hard as switching from 1.* to 2.0 because, I guess, most of the code base of the 3.0 will remain unchanged in comparison with the latest 2.* version. Though there should be significant changes and BC to justify a major version bump. IMHO in this case we shouldn't be scared about BC as they should be seen as good chances to make things even better.

I also agree with @lsmith77 when he says:

that it makes sense to try and make a decision about 2.8 vs. 3.0 sooner rather than later as this might also enable us to work more on some forwards compatibility features that might make the move less painful.

So being able to state things clear early will allow all of us to propose suggestions about how to deal with new possible breaking changes and take smarter decisions together.

Let's rock on! :wink:

@g-g
g-g commented

We use symfony for some long running projects, that keep getting improved for years. We are stuck with still actively developed 1x projects, and everybody hates to work on them.
If there is no upgrade path from 2.x to 3.x, we will not be able to use symfony any more, because we simply cannot afford to have symfony 1.x, 2.x and 3.x experts on the team.
So let's rock on, but please don't leave a 2.x zombie behind ;-)

@pyrech

Is there a list of planned changes waiting for 3.0? I think about the split of the HttpKernel component (#9406 and #10374), the split of the ConfigComponent (#7796), a redesign of the Request class (#6406)...
Anyway, a quick search by milestone (symfony/symfony/milestones/3.0) give already some clues about what's coming in 3.0

@dirkluijk

If 3.0 is just another 2.x with (some?) BC changes and new features, it should be no big deal and must therefor not be compared to 1.x to 2.0 at all. Without the BC promise it could have been 2.8 anyway - at least for most parts.

Or I have missed some big changes that would make 3.x a lot more different than 2.x - what about Hack? @fabpot what is your vision regarding Symfony and HHVM/Hack?

@stof stof added this to the 3.0 milestone
@stof stof added the RFC label
@fabpot
Owner

ber

@fabpot fabpot closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.