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.
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.
> 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.
> This leads me to a marketing concern: Should we call the next release > "symfony 1.1" or "symfony 2.0"?
I agree that 1.1 sounds a bit undernumbered regarding new features and enhancements. As Firefox did, we could also think about a 1.5 version, but definitely not a 1.1 to me. Also, as Fabien has began to communicate around the 2.0 version (SymfonyCamp slides are circulating on the web), naming actual 1.1 version 2.0 could confuse some minds.
++
-- Nicolas Perriault http://www.clever-age.com Clever Age - conseil en architecture technique GSM: +33 6 60 92 08 67 Tél: +33 1 53 34 66 10
I agree 1.5 would fit better. 1.1 sounds like a 'slight feature update' but the changes are quite mayor. As said Fabien already presented his ideas and some code-samples for the 2.0 release at SymfonyCamp, and because BC is almost fully ensured, the major version number should not change.
> 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.
"As the so-called "Symfony 1.1" is not a revolution of Symfony's core"
This is quite the contrary. A LOT has changed in the core but users won't have to change a lot of things in their applications to make it work with symfony 1.1 (most of the changes are automated by the symfony project:upgrade task anyway).
But, you're also right, because this new release works with the same logic as far as the controller/filters/... works. So, no major changes here. symfony 2.0 will have major changes in the way we implement the Controller pattern (see my symfonyCamp presentation for more information).
Here is another major reason why I think 1.5 is good compromise:
- we are committed to provide support for symfony 1.0 - symfony 1.1/1.5/whatever is "just" a transition release (like 0.6.3 in the past) - symfony 2.0 will be a release that will be supported for a long period of time.
> 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.
>> This leads me to a marketing concern: Should we call the next release >> "symfony 1.1" or "symfony 2.0"?
> I agree that 1.1 sounds a bit undernumbered regarding new features and > enhancements. As Firefox did, we could also think about a 1.5 version, > but definitely not a 1.1 to me. Also, as Fabien has began to communicate > around the 2.0 version (SymfonyCamp slides are circulating on the web), > naming actual 1.1 version 2.0 could confuse some minds.
> > This leads me to a marketing concern: Should we call the next release > > "symfony 1.1" or "symfony 2.0"?
> I agree that 1.1 sounds a bit undernumbered regarding new features and > enhancements. As Firefox did, we could also think about a 1.5 version, > but definitely not a 1.1 to me. Also, as Fabien has began to communicate > around the 2.0 version (SymfonyCamp slides are circulating on the web), > naming actual 1.1 version 2.0 could confuse some minds.
> ++
> -- > Nicolas Perriault http://www.clever-age.com > Clever Age - conseil en architecture technique > GSM: +33 6 60 92 08 67 Tél: +33 1 53 34 66 10
> 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.
> What are your thoughts on the subject?
> François
I also think 1.5 is the best compromise (as much as I have a say, of course ;))
> > 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.
> > What are your thoughts on the subject?
> > François
> I also think 1.5 is the best compromise (as much as I have a say, of > course ;))
> Kupo
-- Dave Dash 612.670.0621 Discover your favorite restaurant: reviewsby.us gtalk: dave.dash
I'm not interested in "marketing versions" and my customers have no real idea what symfony is at all.. ;-) 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. ;-)
Regards, Matthias
On 26 Sep., 14:03, "Francois Zaninotto" <francois.zanino...@symfony-
> 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.
project.com> wrote: > "As the so-called "Symfony 1.1" is not a revolution of Symfony's core"
> This is quite the contrary. A LOT has changed in the core but users > won't have to change a lot of things in their applications to make it > work with symfony 1.1 (most of the changes are automated by the symfony > project:upgrade task anyway).
> But, you're also right, because this new release works with the same > logic as far as the controller/filters/... works. So, no major changes > here. symfony 2.0 will have major changes in the way we implement the > Controller pattern (see my symfonyCamp presentation for more information).
> Here is another major reason why I think 1.5 is good compromise:
> - we are committed to provide support for symfony 1.0 > - symfony 1.1/1.5/whatever is "just" a transition release (like 0.6.3 in > the past) > - symfony 2.0 will be a release that will be supported for a long period > of time.
Matthias N. wrote: > I'm not interested in "marketing versions" and my customers have no > real idea what symfony is at all.. ;-) > 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. ;-)
>> 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.
>> What are your thoughts on the subject?
>> François
The main idea is that it does not hurt to be 1.5 and it can only bring benefit by making newcomers think why it is 1.5 and then they can see at all the new features and the changes to the core and it will make sense. The idea is to bring peoples attention to the enhancements. I remember comments before I started working with Symfony when it was 0.63 or something and the comments were that Symfony is more stable and feature rich than many 1.0+ frameworks. There are still many PHP developers not using a framework and many are looking for alternatives and, yes, more people using it more progress, more innovation, more plugins... less work all of us have to do in the end :)
Hi Tristan, Version numbers ARE marketing. Even if that marketing targets technical people. It is the very first indicator of maturity (but hehe, you should keep your promises here). The difference between version numbers is an indicator for change. And, as said also for compatibility indication. But if you are not tapestry, then you might manage to do a major version number without rewriting the whole api.
If you are really just interested in the technical numbering a build or revision number might be enough for you. Hey its symfony r8343! Doesn't sound exiting?
grbounce-E0w9TwUAAADi0IHzGDPpnb3xZnFj_s-y=fabian.lange=web...@googlegroups.c om [mailto:grbounce-E0w9TwUAAADi0IHzGDPpnb3xZnFj_s-y=fabian.lange=web.de@googl e groups.com] On Behalf Of Tristan Rivoallan Sent: Mittwoch, 26. September 2007 15:37 To: symfony-devs@googlegroups.com Subject: [symfony-devs] Re: Should symfony 1.1 be called symfony 2.0?
2007/9/26, Jo <u.nits...@gmail.com>: > I don't see any reason not to call it symfony 1.1. > It is the next release and one (big) step ahead.
> Calling it symfony 1.5 or 2.0 I would wonder if > I've missed the last releases and what happend > between release 1.0 and 1.5 (or 2.0).
> Does symfony really need marketing by release > numbers?
+1. If we really want to do release marketing, then call it Symfony Millenium. Otherwise, keep a normal numbering scheme seems better to me.
the linux kernel will not even go beyond 2.6 ...
we want people to be attracted by framework's technical quality right ? a consistent numbering scheme is part of software component's quality
bad marketing when dealing with technical software imho. especially F/OSS software.
> Even if that marketing targets technical people.
i agree. But for me a consistent roadmap is a sign of good technical health of the project. With project leaders who know what they are doing.
when evaluating software, i'm always concerned when there are gaps in the numbering scheme. You can never know what it means : unreleased version due to showstoppers ? enthusiastic marketing ?
uncertainty is never a good thing when looking at a software history. symfony is aimed at being an "enterprise" framework. Thus it will be evaluated by consulting companies who care about this kind of things.
> It is the very first indicator of maturity (but hehe, you should > keep your promises here). The difference between version numbers is an > indicator for change. And, as said also for compatibility indication.
indeed. imo : * going from 0.6.3 to 1.0.0 means : you are now using stable software * going from 1.0.0 to 1.0.x means : minor security / feature fix, absolute BC * going from 1.0.x to 1.1.x means : new features & bugfixes, manageable BC breaks * going from 1.x to 2.x means : unmanageable BC breaks * going from 1.0 to 1.5 means : WTF ?
> If you are really just interested in the technical numbering a build or > revision number might be enough for you. > Hey its symfony r8343!
i'm interested in meaningful numbering
> Doesn't sound exiting?
not quite. but neither does 1.5 nor 1.1. The exciting part is the changelog, and if you really want product name marketing, i guess we should try to have "named" releases : * 0.6.3 - André Rieux * 1.0.0 - Schubert * 1.1.0 - Chopin
I agree with this. Calling the new symfony version 1.5 would simply be marketing. I think it would be much wiser to stick to a good, solid versioning. Since the current version is 1.0, and the new version is the next big improvement, following the most versioning systems this should either be 1.1 (next big thing) or 1.2 (following the logic of all odd numbers being the development version of the next stable release, and the next stable release being an even number).
Calling is 1.5 would be nothing but marketing, and with a framework like symfony, it should be necessary to do that. Developers are the people who will be using it daily, and they give more about a logical versioning.
Just my 2 cents
Stefan
On Sep 26, 3:30 pm, Jo <u.nits...@gmail.com> wrote:
On Sep 26, 6:58 pm, "Fabian Lange" <Fabian.La...@web.de> wrote:
> Version numbers ARE marketing.
I highly disagree. Good versioning is essential for (technical) project management. Version numbers are identifiers of the various steps in software development. So version numbers are absolutely not marketing. They can be used for that, but if you use it purely for version management, it's got nothing to do with marketing.
Wait, someone tells me that odd numbered version are considered as somewhat instable ones ! So may I suggest a pretty 1.2 ?
Just joking here, it's just software, features and true maturity are more important than version numbering (at least, it should be incremental) - 1.1, 1.5 or 2.0, Symfony will rock, that's enough for me.
++
PS: I love the "André Rieux"-like naming system !
-- Nicolas Perriault http://www.clever-age.com Clever Age - conseil en architecture technique GSM: +33 6 60 92 08 67 Tél: +33 1 53 34 66 10
Chopin > Schubert? Are you trying to cause some kind of classical music flame war? ;-)
More seriously, I just wanted to express my preference for sticking with a steady version number scheme. I agree with Tristan that the jump to 1.x made sense because it communicated stability, and a jump to 2.x will make sense when the changes are major enough that users should expect serious breakage. Otherwise I don't see much benefit to be gained in engaging in the version number arms-race game.
David Brewer
On 9/26/07, Tristan Rivoallan <trivoal...@clever-age.com> wrote:
> Chopin > Schubert? Are you trying to cause some kind of classical > music flame war? ;-)
> More seriously, I just wanted to express my preference for sticking > with a steady version number scheme. I agree with Tristan that the > jump to 1.x made sense because it communicated stability, and a jump > to 2.x will make sense when the changes are major enough that users > should expect serious breakage. Otherwise I don't see much benefit to > be gained in engaging in the version number arms-race game.
My own feeling is that jumping to a 1.5 version number wouldn't be a number race, the goal is different.
This version is a major improvement of the architecture of Symfony 1.0, and I guess that there won't be any other such great change in the Symfony 1.x family before the launch of Symfony 2.0.
This version could therefore be seen as an intermediate version, the final great improvement before a brand new architecture, which development has already started.
Sure, you can consider that the proposal of a 1.5 number is only a marketing numbering. Sure, you can choose to stick to mechanic numbers. But being mechanical has never been proved to be the most clever way of doing things.
From my point of view, stamping this new release with a "1.5" number would be a great way to communicate about Symfony, as it would show to non-specialists that the framework is living and improving fast. If calling this new release "Symfony 1.5" instead of a pale "Symfony 1.1" permits to spread Symfony and make more people gain an interest for it, then there is no doubt that it is what we have to do, no matter the numbering you saw in some other OSS projects.
Hi Stefan, you missed the point. Marketing is transporting a message. And you exactly say that you get various aspects from a version number transported. The whole discussion shows that version numbers are marketing. For version management you have trac. If you really just want to release a new version do a continuous numbering from 1-n You could even tag which version is compatible with what.
But naming symfony 1.0 - 1.0 was already marketing transporting a special message that is easier for people to under stand rather than reading release notes checking changesets and checking api deprecation. Same is calling it 1.0.1. This shall mean this is fully compatible, we just fixed some minor stuff, take it asap. But you could otherwise say: revison 2345 has now been tagged as stable release 4. Its compatible with revision r1223-2344, releases 2-4. Check the modification in classes x and y.
But that's hard to grasp and doesn't fit onto a box. So 1.5 would transport a message most people here agree on (btw: I don't, because the list from Francois does not contain really new "features" It contains mostly invisible enhancements, and I would like to see visible enhancements for such a major jump). And 1.5 would fit on a box.
Giving it an additional name is just decoration. Because the name is not marketing, it does not transport a message.
grbounce-E0w9TwUAAADi0IHzGDPpnb3xZnFj_s-y=fabian.lange=web...@googlegroups.c om [mailto:grbounce-E0w9TwUAAADi0IHzGDPpnb3xZnFj_s-y=fabian.lange=web.de@googl e groups.com] On Behalf Of Stefan Koopmanschap Sent: Mittwoch, 26. September 2007 21:23 To: symfony developers Subject: [symfony-devs] Re: Should symfony 1.1 be called symfony 2.0?
On Sep 26, 6:58 pm, "Fabian Lange" <Fabian.La...@web.de> wrote: > Version numbers ARE marketing.
I highly disagree. Good versioning is essential for (technical) project management. Version numbers are identifiers of the various steps in software development. So version numbers are absolutely not marketing. They can be used for that, but if you use it purely for version management, it's got nothing to do with marketing.
Stefan Koopmanschap wrote: > Since the current version is 1.0, and the new version is the next big > improvement, following the most versioning systems this should either > be 1.1 (next big thing) or 1.2 (following the logic of all odd > numbers being the development version of the next stable release, and > the next stable release being an even number).
+1 for 1.2, for exactly that reason. Anyone remembering the discussion we had when 0.7 was becoming stable? IIRC something like this even/odd numbering scheme was the plan, wasn't it? Furthermore: it just looks like a bigger step... ;)
One more thing about this that I just thought of: What about the future? If symfony 2.0 is improved, then what? Will that be released as symfony 2.5? If you choose a versioning scheme, you got to stick with it. If you now choose to make the next version symfony 1.5, that implicate that the new release after symfony 2.0 would be 2.5 ...
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.
