> When I look at the trunk version of symfony, I see a lot of new and exciting > stuff, among which:
> - New CLI task system > - New plugin system > - New mixin/event system > - Improved caching system > - Total decoupling of objects > - Better exceptions > - Better routing > - Better logging > - Better storage > - More factories > - Less singletons > - I probably forgot some > - And many, many small improvements.
> This leads me to a marketing concern: Should we call the next release > "symfony 1.1" or "symfony 2.0"? With all the new stuff in there, calling it > 1.1 would really be a poor choice (especially if you compare it with what > rails put in its 1.1...), spoiling the enhancements. On the other hand, > calling it symfony 2.0 might frighten people, especially BC wise.
I don't think the changes you listed deserve to be summarized as Symfony 2.0; they simply mean improved functionality and/or refactoring of what's already in 1.0. Hence, it should be called 1.1 (or 1.2 if you choose to give development branches odd numbers).
The day Symfony gets a new, written from scratch forefront feature of any web framework - form validation/update, making it *useful* and *enjoyable*, - definitely not what it has now - then it should definitely be Symfony 2.0. Until then, it's too early.
If you're simply choosing a release number for marketing purposes, then call it 2.0 up to 10.0 or 20.0 like Solaris or Emacs did (not at all meaning they have bad software).
I'd agree with Xavier and others on this one, 1.1 just doesn't cut it (nor do it justice).
Having version 1.5 gives developers a real sense, that Symfony is heading towards 2.0 - the next, incompatible, but better, version of the framework. This version should be perceived as a gateway/stepping stone towards 2.0, stimulating early adoption and lessening the fear of migration towards 2.0, since the jump from 1.5 to 2.0 won't be as psychologically daunting as previously thought.
Again, assuming that proper support for migrating 1.x projects to 2.0 does exist.
-Klmn
On Sep 26, 2:11 pm, Xavier Lacot <xla...@clever-age.com> wrote:
> I fully agree with you, even though I fear that some people might be > frightened of BC breaks. Wouldn't a version called "1.5" be a good > compromise ? Other successful open-source projects have used this number > for major improvements (Mozilla Firefox, for instance). As the so-called > "Symfony 1.1" is not a revolution of Symfony's core, keeping the major > number "1" sounds to me the best solution.
> xavier
> Francois Zaninotto a écrit :
> > Hi list,
> > When I look at the trunk version of symfony, I see a lot of new and > > exciting stuff, among which:
> > - New CLI task system > > - New plugin system > > - New mixin/event system > > - Improved caching system > > - Total decoupling of objects > > - Better exceptions > > - Better routing > > - Better logging > > - Better storage > > - More factories > > - Less singletons > > - I probably forgot some > > - And many, many small improvements.
> > All in all, the question about symfony 1.1 is more "what hasn't changed" > > rather that "what has changed". The best part is that all that has > > changed almost never breaks BC, which means that existing applications > > will most of the time be able to take advantage of the new features.
> > This leads me to a marketing concern: Should we call the next release > > "symfony 1.1" or "symfony 2.0"? With all the new stuff in there, calling > > it 1.1 would really be a poor choice (especially if you compare it with > > what rails put in its 1.1...), spoiling the enhancements. On the other > > hand, calling it symfony 2.0 might frighten people, especially BC wise.
> > We know Fabien has great plans for after this next release, but their > > version number could very well be 3.0 or 4.0.
> > Last but not least, symfony 1.0 was released eight months ago, and no > > enhancement was officially published since then. I think symfony > > deserves a strong version upgrade to show that the development is very > > active.
If sticking to "odd for dev" convention, even numbered version like 1.2.0 would be the choice. I can live with 1.5 (and actually whatever version) but this breaks the odd=dev convention and a 1.0 to 1.4.0 / 1.6.0 bump simply look strange.
On Sep 27, 5:30 pm, Tony Piper <tony.pi...@gmail.com> wrote:
> > For me it doesn't matter if the next release is 1.1 or 1.5 - it only > > matters what I can do with it. And that is already VERY IMPRESSIVE! > > If the new helpers / form / validation system is as half as good as > > the enhancements I've already seen then I will buy 10 books. ;-)
> There's an idea. If the changes are so big as to warrant a new > physical book edition then jump up a major version. If not, jump a > minor. Being able to buy the book was, for me, a major factor in > choosing to spend time learning Symfony.
> As long as 1.1/1.5/2.0 isn't eternally delayed (like CakePHP) I'm > happy.
When talking in a business layer with other people in any project, the linux kernel method looks good.( 2.6.20.x stable, 2.6.21.x dev( it's become a 22 stable) ), much more with not IT people. Why? to a quick assign of status of development and a speed/activity off dev that way can be more helpfull.
according with first Francois post, IMHO, the next release can be named 1.5, or better 1.9. :-D.
but, Francois, usually major versions increases when core part of framework/project/wathever did a BC or change much things of first concepts of the framework, then I ask you, what we can define what is core part of symfony and what is not ? this can help in that kind of questions
> If sticking to "odd for dev" convention, even numbered version like > 1.2.0 would be the choice. > I can live with 1.5 (and actually whatever version) but this breaks > the odd=dev convention and a 1.0 to 1.4.0 / 1.6.0 bump simply look > strange.
> On Sep 27, 5:30 pm, Tony Piper <tony.pi...@gmail.com> wrote: > > On Sep 26, 4:46 pm, "Matthias N." <matthias.nothh...@googlemail.com> > > wrote:
> > > For me it doesn't matter if the next release is 1.1 or 1.5 - it only > > > matters what I can do with it. And that is already VERY IMPRESSIVE! > > > If the new helpers / form / validation system is as half as good as > > > the enhancements I've already seen then I will buy 10 books. ;-)
> > There's an idea. If the changes are so big as to warrant a new > > physical book edition then jump up a major version. If not, jump a > > minor. Being able to buy the book was, for me, a major factor in > > choosing to spend time learning Symfony.
> > As long as 1.1/1.5/2.0 isn't eternally delayed (like CakePHP) I'm > > happy.
> When talking in a business layer with other people in any project, the > linux > kernel method looks good.( 2.6.20.x stable, 2.6.21.x dev( it's become a 22 > stable) ), much more with not IT people.
Not really on topic anymore but FYI: the even=stable/odd=unstable scheme has been abandoned in the kernel about 2 years ago. That's why they've built quite a lot of new stuff into it but there still isn't a 2.7.x branch for development. Currently, work is being done on the 2.6.23 kernel and when that's released it's officially a stable version. The release candidates are for development and testing.
> Why? to a quick assign of status of development and a speed/activity off > dev > that way can be more helpfull.
> according with first Francois post, IMHO, the next release can be named > 1.5, > or better 1.9. :-D.
> but, Francois, usually major versions increases when core part of > framework/project/wathever did a BC or change much things of first > concepts > of the framework, then I ask you, what we can define what is core part of > symfony and what is not ? > this can help in that kind of questions
> When talking in a business layer with other people in any project, the > linux > kernel method looks good.( 2.6.20.x stable, 2.6.21.x dev( it's become a 22 > stable) ), much more with not IT people.
Not really on topic anymore but FYI: the even=stable/odd=unstable scheme has been abandoned in the kernel about 2 years ago. That's why they've built quite a lot of new stuff into it but there still isn't a 2.7.x branch for development. Currently, work is being done on the 2.6.23 kernel and when that's released it's officially a stable version. The release candidates are for development and testing.
> Why? to a quick assign of status of development and a speed/activity off > dev > that way can be more helpfull.
> according with first Francois post, IMHO, the next release can be named > 1.5, > or better 1.9. :-D.
> but, Francois, usually major versions increases when core part of > framework/project/wathever did a BC or change much things of first > concepts > of the framework, then I ask you, what we can define what is core part of > symfony and what is not ? > this can help in that kind of questions
Bert-Jan wrote: >> that point exposed by Tamcy is important.
>> When talking in a business layer with other people in any project, the >> linux >> kernel method looks good.( 2.6.20.x stable, 2.6.21.x dev( it's become a 22 >> stable) ), much more with not IT people.
> Not really on topic anymore but FYI: the even=stable/odd=unstable scheme > has been abandoned in the kernel about 2 years ago. That's why they've > built quite a lot of new stuff into it but there still isn't a 2.7.x > branch for development. Currently, work is being done on the 2.6.23 kernel > and when that's released it's officially a stable version. The release > candidates are for development and testing.
>> Why? to a quick assign of status of development and a speed/activity off >> dev >> that way can be more helpfull.
>> according with first Francois post, IMHO, the next release can be named >> 1.5, >> or better 1.9. :-D.
>> but, Francois, usually major versions increases when core part of >> framework/project/wathever did a BC or change much things of first >> concepts >> of the framework, then I ask you, what we can define what is core part of >> symfony and what is not ? >> this can help in that kind of questions
> even and odd versions were used before the symfony 1.0 release. We don't > use them anymore.
> Fabien
> Bert-Jan wrote: > >> that point exposed by Tamcy is important.
> >> When talking in a business layer with other people in any project, the > >> linux > >> kernel method looks good.( 2.6.20.x stable, 2.6.21.x dev( it's become a > 22 > >> stable) ), much more with not IT people.
> > Not really on topic anymore but FYI: the even=stable/odd=unstable scheme > > has been abandoned in the kernel about 2 years ago. That's why they've > > built quite a lot of new stuff into it but there still isn't a 2.7.x > > branch for development. Currently, work is being done on the 2.6.23kernel > > and when that's released it's officially a stable version. The release > > candidates are for development and testing.
> >> Why? to a quick assign of status of development and a speed/activity > off > >> dev > >> that way can be more helpfull.
> >> according with first Francois post, IMHO, the next release can be named > >> 1.5, > >> or better 1.9. :-D.
> >> but, Francois, usually major versions increases when core part of > >> framework/project/wathever did a BC or change much things of first > >> concepts > >> of the framework, then I ask you, what we can define what is core part > of > >> symfony and what is not ? > >> this can help in that kind of questions
project.com> wrote: > even and odd versions were used before the symfony 1.0 release. We don't > use them anymore.
> Fabien
> Bert-Jan wrote: > >> that point exposed by Tamcy is important.
> >> When talking in a business layer with other people in any project, the > >> linux > >> kernel method looks good.( 2.6.20.x stable, 2.6.21.x dev( it's become a 22 > >> stable) ), much more with not IT people.
> > Not really on topic anymore but FYI: the even=stable/odd=unstable scheme > > has been abandoned in the kernel about 2 years ago. That's why they've > > built quite a lot of new stuff into it but there still isn't a 2.7.x > > branch for development. Currently, work is being done on the 2.6.23 kernel > > and when that's released it's officially a stable version. The release > > candidates are for development and testing.
> >> Why? to a quick assign of status of development and a speed/activity off > >> dev > >> that way can be more helpfull.
> >> according with first Francois post, IMHO, the next release can be named > >> 1.5, > >> or better 1.9. :-D.
> >> but, Francois, usually major versions increases when core part of > >> framework/project/wathever did a BC or change much things of first > >> concepts > >> of the framework, then I ask you, what we can define what is core part of > >> symfony and what is not ? > >> this can help in that kind of questions
The odd/even numbering was great since then, I dont really see why this have to change. 1.1 is a developement version since a bit of time, then I put a big +1 on 1.2 version. I personally don't care about version number marketting, otherwise i'd never have used symfony 0.4 which was already great at this time. And afterall, 1.2 or 2.0, who cares? we're developpers, we do not try to by the flashiest vacuum... The most important thing to me in this topic is that BC is kept, mostly thanks to the upgrade task. imo, remaining part of the topic is mostly troll-like, and whatever next stable release of symfony will be, I will never use it for the number written on it.
Romain
2007/10/3, Stefan Koopmanschap <stefan.koopmansc...@gmail.com>:
> Care to elaborate on the reason for abandoning this scheme? I'm quite > curious as to why this was abandoned
> Stefan
> On Oct 2, 12:24 pm, Fabien POTENCIER <fabien.potenc...@symfony- > project.com> wrote: > > even and odd versions were used before the symfony 1.0 release. We don't > > use them anymore.
> > Fabien
> > Bert-Jan wrote: > > >> that point exposed by Tamcy is important.
> > >> When talking in a business layer with other people in any project, > the > > >> linux > > >> kernel method looks good.( 2.6.20.x stable, 2.6.21.x dev( it's become > a 22 > > >> stable) ), much more with not IT people.
> > > Not really on topic anymore but FYI: the even=stable/odd=unstable > scheme > > > has been abandoned in the kernel about 2 years ago. That's why they've > > > built quite a lot of new stuff into it but there still isn't a 2.7.x > > > branch for development. Currently, work is being done on the 2.6.23kernel > > > and when that's released it's officially a stable version. The release > > > candidates are for development and testing.
> > >> Why? to a quick assign of status of development and a speed/activity > off > > >> dev > > >> that way can be more helpfull.
> > >> according with first Francois post, IMHO, the next release can be > named > > >> 1.5, > > >> or better 1.9. :-D.
> > >> but, Francois, usually major versions increases when core part of > > >> framework/project/wathever did a BC or change much things of first > > >> concepts > > >> of the framework, then I ask you, what we can define what is core > part of > > >> symfony and what is not ? > > >> this can help in that kind of questions
Then it seems ok for 1.5 or even 2.0, obviously the change to symfony core is much more than expected. Just one concern: If it is 1.5, I feel more comfortable that it keeps compatibility to deprecated stuff like function helpers, which should be dumped by 2.0. The compatibility plugin(?) for 1.0 should be shipped with the next stable version, am I correct?
On Oct 2, 6:24 pm, Fabien POTENCIER <fabien.potenc...@symfony-
project.com> wrote: > even and odd versions were used before the symfony 1.0 release. We don't > use them anymore.
> Fabien
> Bert-Jan wrote: > >> that point exposed by Tamcy is important.
> >> When talking in a business layer with other people in any project, the > >> linux > >> kernel method looks good.( 2.6.20.x stable, 2.6.21.x dev( it's become a 22 > >> stable) ), much more with not IT people.
> > Not really on topic anymore but FYI: the even=stable/odd=unstable scheme > > has been abandoned in the kernel about 2 years ago. That's why they've > > built quite a lot of new stuff into it but there still isn't a 2.7.x > > branch for development. Currently, work is being done on the 2.6.23 kernel > > and when that's released it's officially a stable version. The release > > candidates are for development and testing.
> >> Why? to a quick assign of status of development and a speed/activity off > >> dev > >> that way can be more helpfull.
> >> according with first Francois post, IMHO, the next release can be named > >> 1.5, > >> or better 1.9. :-D.
> >> but, Francois, usually major versions increases when core part of > >> framework/project/wathever did a BC or change much things of first > >> concepts > >> of the framework, then I ask you, what we can define what is core part of > >> symfony and what is not ? > >> this can help in that kind of questions
I think we need to stop this thread now. From what I understand from this thread, here is my decision:
- Next version of symfony will be 1.1 as we always said.
- 1.1 will be bundled with the sfCompat10Plugin (it contains the old helpers and validators, fill in filter, the 1.0 execution filter, phpmailer, bridges, the sfProcessCache class, ...).
- The sfCompat10Plugin won't be included in symfony 1.2
- symfony 2.0 will have a different philosophy for the controller implementation and won't be compatible with symfony 1.X
Tamcy wrote: > Then it seems ok for 1.5 or even 2.0, obviously the change to symfony > core is much more than expected. > Just one concern: If it is 1.5, I feel more comfortable that it keeps > compatibility to deprecated stuff like function > helpers, which should be dumped by 2.0. The compatibility plugin(?) > for 1.0 should be shipped with the next > stable version, am I correct?
> On Oct 2, 6:24 pm, Fabien POTENCIER <fabien.potenc...@symfony- > project.com> wrote: >> even and odd versions were used before the symfony 1.0 release. We don't >> use them anymore.
>> Fabien
>> Bert-Jan wrote: >>>> that point exposed by Tamcy is important. >>>> When talking in a business layer with other people in any project, the >>>> linux >>>> kernel method looks good.( 2.6.20.x stable, 2.6.21.x dev( it's become a 22 >>>> stable) ), much more with not IT people. >>> Not really on topic anymore but FYI: the even=stable/odd=unstable scheme >>> has been abandoned in the kernel about 2 years ago. That's why they've >>> built quite a lot of new stuff into it but there still isn't a 2.7.x >>> branch for development. Currently, work is being done on the 2.6.23 kernel >>> and when that's released it's officially a stable version. The release >>> candidates are for development and testing. >>>> Why? to a quick assign of status of development and a speed/activity off >>>> dev >>>> that way can be more helpfull. >>>> according with first Francois post, IMHO, the next release can be named >>>> 1.5, >>>> or better 1.9. :-D. >>>> but, Francois, usually major versions increases when core part of >>>> framework/project/wathever did a BC or change much things of first >>>> concepts >>>> of the framework, then I ask you, what we can define what is core part of >>>> symfony and what is not ? >>>> this can help in that kind of questions
|
