Ok, I see your points of having a more flexible versioning of myfaces-impl (as Martin says, myfaces-api is not going to change ever, a part from bug fixing). The only thing is that I think is more natural to the standard user to know which jsf is implemented by looking just at the version of the myfaces-impl, instead of having to go through documentation, and the confusion can be greater when myfaces-impl 2.0 and jsf-ri 2.0 are out there, both artifacts implementing different versions of the spec. Of course, I know that they are completely different things, but not everyone does. Development-wise I am with you that myfaces-2.0 would be more meaningful and flexible and I like it, but I think it is a matter of compromise to avoid future confusion.
This is one of the issues with more controversy since a while! Bruno On 22/05/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
Bruno, Regardless if the version number, I would expect the community and PMC would prevent this from occurring. Paul Spencer Bruno Aranda wrote: > Hi, I can imagine a free evolution of myfaces-impl, but this would > come at a cost of incompatibility with the RI. If we add new > signatures and other artifacts depend on those signatures, that > artifact is depending in the implementation and cannot be used with > other implementations (e.g. RI). Is this really what we want? This is > why I think that the impl should not grow and should be restricted to > be *just* an implementation of the api. > > My 2 pences, > > Bruno > > On 22/05/07, Martin Marinschek <[EMAIL PROTECTED]> wrote: > >> I've always been of Manfred's opinion - it would be better to decouple >> spec version numbers from implementation version numbers, so I'm... >> >> +1 for MyFaces-Impl 2.0 >> >> if we don't do that, we force ourselves into an artifical corset in >> which we cannot move - we can only increment minor version numbers, >> and that means that almost no changes have been committed (users would >> expect only bug-fixes), whereas the implementation could grow in >> functionality significantly independent from the spec. >> >> MyFaces API can stay with a version number of 1.2, though >> >> regards, >> >> Martin >> >> On 5/21/07, Zubin Wadia <[EMAIL PROTECTED]> wrote: >> > It is a discussion about the core - I am only trying to establish >> WHY there >> > are two schools of thought on this - refer to Manfred's post to this >> thread >> > on May 18th. >> > >> > Cheers, >> > >> > Z. >> > >> > >> > On 5/21/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote: >> > > I thought we were simply discussing MyFaces Core. >> > > >> > > Let me clarify my vote: >> > > >> > > +1 1.2 MyFaces Core for JSF 1.2. >> > > -1 2.0 MyFaces Core for JSF 1.2. >> > > >> > > Don't care for Tomahawk/Trinidad/Tobago. These are no longer >> > > tightly-coupled to a specific MyFaces core release, and should use >> > > whatever versions make the most sense. This is already true for >> > > "shared", Trinidad, and Tobago. It's going to happen anyway for >> > > Tomahawk once Myfaces 1.2 becomes trunk since Myfaces 1.1 releases >> are >> > > going to be few and far between once the majority of committers have >> > > switched to 1.2. >> > > >> > > While there have been matching releases for Tomahawk and Core up to >> > > this point, this has been due to the elimination of the previous >> > > coupling between Core and Tomahawk (a process that was more involved >> > > and took longer than anyone expected). >> > > >> > > For tomahawk, my "don't care" suggestion for versioning would be to >> > > use the same version as "shared" as long as that makes sense. >> > > >> > > >> > > On 5/21/07, Zubin Wadia <[EMAIL PROTECTED]> wrote: >> > > > There will always be an impedence mismatch here because MyFaces no >> > longer >> > > > represents the "Spec" but also various component projects. So I see >> > > > Manfred/Matze's point. >> > > > >> > > > This is why I have always advocated letting the Component >> initiatives >> > reign >> > > > alone in terms of their version order, release frequency and >> alignment >> > with >> > > > MyFaces and/or the Sun RI. >> > > > >> > > > And to think that we have the same exposure as the Tomcat >> community is >> > > > pushing it. We are nowhere near as big as them - yet. >> > > > >> > > > So while they can start naming their releases after varieties of >> > Hibiscus >> > > > flowers in the future - we can't. >> > > > >> > > > I'm still +1 on 1.2. >> > > > >> > > > Cheers, >> > > > >> > > > Zubin. >> > > > >> > > > >> > > > On 5/21/07, Bruno Aranda < [EMAIL PROTECTED] > wrote: >> > > > > +1 for 1.2 >> > > > > -1 for 2.0 >> > > > > >> > > > > I do agree that using 2.0 may cause confusion, as unlike what >> happens >> > > > > with tomcat, there will be a future version 2.0 of the spec when >> > > > > myfaces 2.0 is there already. People, unaware of the versioning >> > > > > procedure of the myfaces project, will go and fetch this version >> > > > > thinking that it is the implementation of jsf 2.0. >> > > > > >> > > > > Cheers, >> > > > > >> > > > > Bruno >> > > > > >> > > > > On 21/05/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote: >> > > > > > +1 for 1.2. >> > > > > > -1 for 2.0. >> > > > > > >> > > > > > I see no advantage to using major version numbers which >> differ from >> > > > > > the spec. I see the disadvantage of confusion. >> > > > > > >> > > > > > Also, Manfred, you can have a -1 vote on this issue, but not >> a veto. >> > > > > > >> > > > > > "Vetos only apply to code changes; they do not apply to >> procedural >> > > > > > issues such as software releases." >> > > > > > http://www.apache.org/foundation/glossary.html >> > > > > > >> > > > > > See also >> > > > > > >> > > > >> > >> http://mail-archives.apache.org/mod_mbox/incubator-general/200606.mbox/[EMAIL PROTECTED] >> >> > > > > > >> > > > > > >> > > > > > >> > > > > > On 5/18/07, Manfred Geiler < [EMAIL PROTECTED] > wrote: >> > > > > > > Hi folks, >> > > > > > > >> > > > > > > Like Paul Spencer I'm also still >> > > > > > > +1 >> > > > > > > for >> > > > > > > MyFaces 1.x.y --> JSF 1.1 >> > > > > > > MyFaces 2.x.y --> JSF 1.2 >> > > > > > > MyFaces 3.x.y --> JSF 2.0 >> > > > > > > MyFaces 4.x.y --> JSF whatever comes next >> > > > > > > >> > > > > > > Here is my explanation for the "why": >> > > > > > > This one is similar to Tomcat version numbering and I do not >> > remember >> > > > > > > anyone complaining about having a Tomcat 5.x that is an >> > implementaion >> > > > > > > of Servlet 2.4 and Tomcat 6.x being a Servlet 2.5 container. >> > > > > > > If there will be a "release vs. spec table" on the MyFaces >> > Homepage >> > > > > > > (like the one on http://tomcat.apache.org/) nobody will >> ever be >> > > > > > > confused. >> > > > > > > The big advantage of having (only) the major number >> aligned to the >> > > > > > > spec is the degree of freedom with minor (x) and fix (y) >> number. >> > It is >> > > > > > > a well known and successful pattern to have this >> major.minor.fix >> > > > > > > version numbering scheme. With the 1.2.x versioning on the >> other >> > hand, >> > > > > > > how could we ever differentiate between a minor release >> (with new >> > > > > > > features and maybe slightly changed API for non-spec >> stuff) and a >> > bug >> > > > > > > fix only release, if we may only count the last number up?! >> > > > > > > Remember the Tomcat jump from 5.0.x to 5.5.x when they did a >> > complete >> > > > > > > rewriting of the core stuff? How could they ever have >> expressed >> > that >> > > > > > > in version numbering if they had stolidly aligned their >> tomcat >> > version >> > > > > > > to the servlet spec 2.4? >> > > > > > > >> > > > > > > And do not forget: >> > > > > > > There is not only the implementation. There are 3 >> component libs >> > under >> > > > > > > the MyFaces umbrella. And IMHO it is much more important >> to align >> > all >> > > > > > > the myfaces stuff (compatible to each other) within one major >> > number >> > > > > > > (2.x) than aligning all the stuff to the spec version. For >> the >> > > > > > > component libs it is even more important to have that >> degree of >> > > > > > > freedom for counting up a minor number whenever there is >> an API >> > change >> > > > > > > and let the minor number unchanged for a bug fix release. >> > > > > > > MyFaces is getting more and more important. Also for tool >> vendors. >> > So >> > > > > > > there will be more and more people and stuff out there >> who/that >> > relies >> > > > > > > on our APIs. We should be oblivious to this responsibility. >> > > > > > > >> > > > > > > Sorry, but this is my binding >> > > > > > > -1 veto >> > > > > > > on having 1.2.x for our next spec 1.2 implementation as >> long as >> > the >> > > > > > > only reason for having 1.2.x is a "cosmetic" reason only >> to help >> > > > > > > people not being confused. >> > > > > > > Perhaps I missed something. If so, please explain to me >> what is a >> > > > > > > proper technical or organizational or consequential reason >> for >> > having >> > > > > > > 1.2.x as version for our next major (sic!) release. >> > > > > > > >> > > > > > > >> > > > > > > Thanks, >> > > > > > > Manfred >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > On 5/18/07, Kito D. Mann <[EMAIL PROTECTED]> wrote: >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > +1 for 1.2 >> > > > > > > > >> > > > > > > > -1 for 2.0 >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > Using a " 2.0" version is going to confuse people. >> > > > > > > > >> > > > > > > > >> > > > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > > > > > > > Kito D. Mann - Author, JavaServer Faces in Action >> > > > > > > > http://www.JSFCentral.com - JavaServer Faces FAQ, news, >> and info >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > * Sign up for the JSF Central newsletter! >> > > > > > > > http://oi.vresp.com/?fid=ac048d0e17 * >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > From: Grant Smith [mailto:[EMAIL PROTECTED] >> > > > > > > > Sent: Friday, May 18, 2007 1:16 PM >> > > > > > > > To: MyFaces Development >> > > > > > > > Subject: Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release >> > plans?) >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > +1 for 1.2 >> > > > > > > > -1 for 2.0 >> > > > > > > > >> > > > > > > > >> > > > > > > > On 5/18/07, Mathias Brökelmann < >> [EMAIL PROTECTED]> >> > wrote: >> > > > > > > > >> > > > > > > > +1 for 1.2 >> > > > > > > > >> > > > > > > > 2007/5/18, Matthias Wessendorf < [EMAIL PROTECTED] >: >> > > > > > > > > So, >> > > > > > > > > >> > > > > > > > > any interest in making this to 2.0.0 ? >> > > > > > > > > >> > > > > > > > > -Matthias >> > > > > > > > > >> > > > > > > > > On 2/23/07, Manfred Geiler <[EMAIL PROTECTED]> >> wrote: >> > > > > > > > > ... >> > > > > > > > > > I am >> > > > > > > > > > +1 for Paul's suggestion: >> > > > > > > > > > JSF 1.1 -> MyFaces 1.x >> > > > > > > > > > JSF 1.2 -> MyFaces 2.x >> > > > > > > > > > >> > > > > > > > > > and I am >> > > > > > > > > > +1 for JSF 2.0 (or JSF6 or whatever) -> MyFaces 3.x >> > > > > > > > > >> > > > > > > > > > --Manfred >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > -- >> > > > > > > > Mathias >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > -- >> > > > > > > > Grant Smith >> > > > > > > >> > > > > > > >> > > > > > > -- >> > > > > > > http://www.irian.at >> > > > > > > Your JSF powerhouse - JSF Consulting, >> > > > > > > Development and Courses in English and >> > > > > > > German >> > > > > > > >> > > > > > > Professional Support for Apache MyFaces >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > >> > > >> > >> > >> >> >> -- >> >> http://www.irian.at >> >> Your JSF powerhouse - >> JSF Consulting, Development and >> Courses in English and German >> >> Professional Support for Apache MyFaces >> > >
