You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Matthias Wessendorf <ma...@apache.org> on 2007/05/18 06:28:36 UTC

MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

So,

any interest in making this to 2.0.0 ?

-Matthias

On 2/23/07, Manfred Geiler <ma...@gmail.com> 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

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Paul McMahan <pa...@gmail.com>.
+1 for 1.2,   based on the advantages of aligning with spec releases.

Best wishes,
Paul


On May 18, 2007, at 12:41 AM, Zubin Wadia wrote:

> +1 for 1.2.
>
> IMO, Save 2.0 for JSF2.0. It's just easier to explain to non- 
> community members that way and keeps it aligned with the spec  
> releases.
>
> Cheers,
>
> Zubin.
>
>
> On 5/18/07, Matthias Wessendorf <ma...@apache.org> wrote: So,
>
> any interest in making this to 2.0.0 ?
>
> -Matthias
>
> On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
>


Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Dennis Byrne <de...@dbyrne.net>.
+1 for JSF 1.2 .  It's more intuitive.

Dennis Byrne

On 5/17/07, Zubin Wadia <zw...@gmail.com> wrote:
>
> +1 for 1.2.
>
> IMO, Save 2.0 for JSF2.0. It's just easier to explain to non-community
> members that way and keeps it aligned with the spec releases.
>
> Cheers,
>
> Zubin.
>
>
> On 5/18/07, Matthias Wessendorf <ma...@apache.org> wrote:
> >
> > So,
> >
> > any interest in making this to 2.0.0 ?
> >
> > -Matthias
> >
> > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
> >
>
>


-- 
Dennis Byrne

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Zubin Wadia <zw...@gmail.com>.
+1 for 1.2.

IMO, Save 2.0 for JSF2.0. It's just easier to explain to non-community
members that way and keeps it aligned with the spec releases.

Cheers,

Zubin.


On 5/18/07, Matthias Wessendorf <ma...@apache.org> wrote:
>
> So,
>
> any interest in making this to 2.0.0 ?
>
> -Matthias
>
> On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
>

RE: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by "Jesse Alexander (KSFD 121)" <al...@credit-suisse.com>.
I can see reasons for making it 2.0 (API-changes) but it is much more
intuitive
to us the same major/minor as the specification-release.

+1 (non-binding) for JSF 1.2 == MyFaces 1.2

Alexander

-----Original Message-----
From: mwessendorf@gmail.com [mailto:mwessendorf@gmail.com] On Behalf Of
Matthias Wessendorf
Sent: Friday, May 18, 2007 6:29 AM
To: MyFaces Development
Subject: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

So,

any interest in making this to 2.0.0 ?

-Matthias

On 2/23/07, Manfred Geiler <ma...@gmail.com> 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

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Martin Marinschek <ma...@gmail.com>.
What about performance enhancements?

regards,

Martin

On 5/22/07, Bruno Aranda <br...@gmail.com> 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 <ma...@gmail.com> 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 <zw...@gmail.com> 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 <mk...@gmail.com> 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 <zw...@gmail.com> 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 < brunoaranda@gmail.com > 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 <mk...@gmail.com> 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/%3C4499A901.2090302@rowe-clan.net%3E
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 5/18/07, Manfred Geiler < manfred.geiler@gmail.com > 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 <km...@virtua.com> 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:work.grant@gmail.com]
> > > > > > > > > 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 < mbroekelmann@googlemail.com>
> > > wrote:
> > > > > > > > >
> > > > > > > > > +1 for 1.2
> > > > > > > > >
> > > > > > > > > 2007/5/18, Matthias Wessendorf < matzew@apache.org >:
> > > > > > > > > > So,
> > > > > > > > > >
> > > > > > > > > > any interest in making this to 2.0.0 ?
> > > > > > > > > >
> > > > > > > > > > -Matthias
> > > > > > > > > >
> > > > > > > > > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
> >
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

RE: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by "Beelen, Marco" <ma...@merck.com>.
Hello all,

I'm a user of the MyFaces implementation of JSF and would like to give my opinion on this.

It appair that there are two opinion on this issue based upon two motivations:

1) Lock the versionnumber of MyFaces to the specifications.
2) Use the common major.minor.patch-versioning-schema independant of the spec-versioning.

The upside of the first option is that users immediately understand which version of JSF they can use a MyFaces release for.
The downside of the first is that the MyFaces communicity 'looses' the option to use the common versioning schema.
Although this might be pervented if the MyFaces-community should decide to use a combination of both by starting to use the schema: specMajor.specMinor.implMajor.implMinor.implPatch.

This would give us:
- MyFaces 1.1.1.1.5 for the current release.
- MyFaces 1.1.2.0.0 for some major rework of the current implementation.
- MyFaces 1.2.1.0.0 for the initial release of a MyFaces Implementation of the JSF 1.2 ( as currently being developed in the trunk )
- MyFaces 2.0.1.0.0 for the first implementation of the JSF 2.0 spec.

Although this could become a problem with the next release which would be 1.1.2.0.0, which is 'lower' then the current 1.1.5-release. Besides using 5 digits for version might be a bit much.

So I don't like the locking of the versioning numbers of MyFaces to the versioning of the JSF-spec.
Although I agree with everybody whom have stated that it would be convenient if the version of MyFaces would directy give information about the version of the jsf-spec, I don't think that MUST be applied.

I think that most people, who use MyFaces, are smart people ( they propably are software developers ;-) ), so they will understand that release x.y.z of myfaces does not neccessary mean that it implements exactly version x.y.z. of some specification.

Of course the website/documentation should specify the implemented version of the spec in such a way, that it can easily be found. ( Like a compatibility matrix or like Tomcat, which has a table on their homepage, which version of tomcat implements each version of the spec. )

My suggestion would be to use the normal major.minor.patch-schema, resulting in:
- use MyFaces 1.x.x for implementation(s) of any JSF 1.1-spec.
- use MyFaces 2.x.x for implementation of the JSF 1.2-spec.
- Deal with the other problems when they emerge.

Possible solution if there ever comes a JSF 2.0-specification: 
* Rename MyFaces to YourFaces ( Change the name from 1st person to 2nd-person, just like the specification )

An consequently on release of JSF 3.0: 
* Rename the product to HerFaces, when it wins the vote over HisFaces. ;-)


With kind regards,
    Marco Beelen





 

-----Original Message-----
From: Bruno Aranda [mailto:brunoaranda@gmail.com] 
Sent: dinsdag 22 mei 2007 15:13
To: MyFaces Development
Subject: Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

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 <pa...@apache.org> 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 <ma...@gmail.com> 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 <zw...@gmail.com> 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 <mk...@gmail.com> 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 <zw...@gmail.com> 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 < brunoaranda@gmail.com > 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 <mk...@gmail.com> 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/%3C4499A901.2090302@rowe-clan.net%3E
> >>
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > On 5/18/07, Manfred Geiler < manfred.geiler@gmail.com > 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 <km...@virtua.com> 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:work.grant@gmail.com]
> >> > > > > > > > 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 <
> >> mbroekelmann@googlemail.com>
> >> > wrote:
> >> > > > > > > >
> >> > > > > > > > +1 for 1.2
> >> > > > > > > >
> >> > > > > > > > 2007/5/18, Matthias Wessendorf < matzew@apache.org >:
> >> > > > > > > > > So,
> >> > > > > > > > >
> >> > > > > > > > > any interest in making this to 2.0.0 ?
> >> > > > > > > > >
> >> > > > > > > > > -Matthias
> >> > > > > > > > >
> >> > > > > > > > > On 2/23/07, Manfred Geiler <ma...@gmail.com>
> >> 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
> >>
> >
> >
>
>




------------------------------------------------------------------------------
Notice:  This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates (which may be known
outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD
and in Japan, as Banyu - direct contact information for affiliates is 
available at http://www.merck.com/contact/contacts.html) that may be 
confidential, proprietary copyrighted and/or legally privileged. It is 
intended solely for the use of the individual or entity named on this 
message. If you are not the intended recipient, and have received this 
message in error, please notify us immediately by reply e-mail and then 
delete it from your system.

------------------------------------------------------------------------------

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Bruno Aranda <br...@gmail.com>.
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 <pa...@apache.org> 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 <ma...@gmail.com> 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 <zw...@gmail.com> 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 <mk...@gmail.com> 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 <zw...@gmail.com> 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 < brunoaranda@gmail.com > 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 <mk...@gmail.com> 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/%3C4499A901.2090302@rowe-clan.net%3E
> >>
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > On 5/18/07, Manfred Geiler < manfred.geiler@gmail.com > 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 <km...@virtua.com> 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:work.grant@gmail.com]
> >> > > > > > > > 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 <
> >> mbroekelmann@googlemail.com>
> >> > wrote:
> >> > > > > > > >
> >> > > > > > > > +1 for 1.2
> >> > > > > > > >
> >> > > > > > > > 2007/5/18, Matthias Wessendorf < matzew@apache.org >:
> >> > > > > > > > > So,
> >> > > > > > > > >
> >> > > > > > > > > any interest in making this to 2.0.0 ?
> >> > > > > > > > >
> >> > > > > > > > > -Matthias
> >> > > > > > > > >
> >> > > > > > > > > On 2/23/07, Manfred Geiler <ma...@gmail.com>
> >> 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
> >>
> >
> >
>
>

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Paul Spencer <pa...@apache.org>.
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 <ma...@gmail.com> 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 <zw...@gmail.com> 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 <mk...@gmail.com> 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 <zw...@gmail.com> 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 < brunoaranda@gmail.com > 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 <mk...@gmail.com> 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/%3C4499A901.2090302@rowe-clan.net%3E 
>>
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On 5/18/07, Manfred Geiler < manfred.geiler@gmail.com > 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 <km...@virtua.com> 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:work.grant@gmail.com]
>> > > > > > > > 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 < 
>> mbroekelmann@googlemail.com>
>> > wrote:
>> > > > > > > >
>> > > > > > > > +1 for 1.2
>> > > > > > > >
>> > > > > > > > 2007/5/18, Matthias Wessendorf < matzew@apache.org >:
>> > > > > > > > > So,
>> > > > > > > > >
>> > > > > > > > > any interest in making this to 2.0.0 ?
>> > > > > > > > >
>> > > > > > > > > -Matthias
>> > > > > > > > >
>> > > > > > > > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 
>> 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
>>
> 
> 


Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Bruno Aranda <br...@gmail.com>.
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 <ma...@gmail.com> 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 <zw...@gmail.com> 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 <mk...@gmail.com> 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 <zw...@gmail.com> 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 < brunoaranda@gmail.com > 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 <mk...@gmail.com> 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/%3C4499A901.2090302@rowe-clan.net%3E
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 5/18/07, Manfred Geiler < manfred.geiler@gmail.com > 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 <km...@virtua.com> 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:work.grant@gmail.com]
> > > > > > > > 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 < mbroekelmann@googlemail.com>
> > wrote:
> > > > > > > >
> > > > > > > > +1 for 1.2
> > > > > > > >
> > > > > > > > 2007/5/18, Matthias Wessendorf < matzew@apache.org >:
> > > > > > > > > So,
> > > > > > > > >
> > > > > > > > > any interest in making this to 2.0.0 ?
> > > > > > > > >
> > > > > > > > > -Matthias
> > > > > > > > >
> > > > > > > > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
>

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Bernhard Huemer <be...@gmail.com>.
Hello,

as far as I know there is no JCP specification using 3 numbers for
versioning. Therefore I would assume it's perfectly valid to reserve
only the first two numbers for the specification version being
implemented. That said, though, decoupling the version number of MyFaces
from the version number of the specification seems rather reasonable to
me.

greetings,
Bernhard Huemer

On 05/22/07, Paul Spencer <pa...@apache.org> wrote:

> I am also in agreement with Manfred's opinion.
> 
> If we tie the MyFaces version number to the spec, what do we do in the following
> cases:
> 1) A fix to the spec is release, i.e. 1.2.1? It is very likely that MyFaces releases
>     will be more frequent then spec releases, thus we can be faces with something like
>     MyFaces 1.2.7 implementing spec version 1.2.1.
> 
> 2) We want top to a major refactoring of MyFaces, similar to Tomcat 5.0 and 5.5?
> 
> Paul Spencer
> 
> Martin Marinschek 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 <zw...@gmail.com> 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 <mk...@gmail.com> 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 <zw...@gmail.com> 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 < brunoaranda@gmail.com > 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 <mk...@gmail.com> 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/%3C4499A901.2090302@rowe-clan.net%3E 
> >>
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > On 5/18/07, Manfred Geiler < manfred.geiler@gmail.com > 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 <km...@virtua.com> 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:work.grant@gmail.com]
> >> > > > > > > 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 < mbroekelmann@googlemail.com>
> >> wrote:
> >> > > > > > >
> >> > > > > > > +1 for 1.2
> >> > > > > > >
> >> > > > > > > 2007/5/18, Matthias Wessendorf < matzew@apache.org >:
> >> > > > > > > > So,
> >> > > > > > > >
> >> > > > > > > > any interest in making this to 2.0.0 ?
> >> > > > > > > >
> >> > > > > > > > -Matthias
> >> > > > > > > >
> >> > > > > > > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 
> >> 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
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >>
> >>
> > 
> > 
> 


Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Paul Spencer <pa...@apache.org>.
I am also in agreement with Manfred's opinion.

If we tie the MyFaces version number to the spec, what do we do in the following
cases:
1) A fix to the spec is release, i.e. 1.2.1? It is very likely that MyFaces releases
    will be more frequent then spec releases, thus we can be faces with something like
    MyFaces 1.2.7 implementing spec version 1.2.1.

2) We want top to a major refactoring of MyFaces, similar to Tomcat 5.0 and 5.5?

Paul Spencer

Martin Marinschek 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 <zw...@gmail.com> 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 <mk...@gmail.com> 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 <zw...@gmail.com> 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 < brunoaranda@gmail.com > 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 <mk...@gmail.com> 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/%3C4499A901.2090302@rowe-clan.net%3E 
>>
>> > > > >
>> > > > >
>> > > > >
>> > > > > On 5/18/07, Manfred Geiler < manfred.geiler@gmail.com > 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 <km...@virtua.com> 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:work.grant@gmail.com]
>> > > > > > > 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 < mbroekelmann@googlemail.com>
>> wrote:
>> > > > > > >
>> > > > > > > +1 for 1.2
>> > > > > > >
>> > > > > > > 2007/5/18, Matthias Wessendorf < matzew@apache.org >:
>> > > > > > > > So,
>> > > > > > > >
>> > > > > > > > any interest in making this to 2.0.0 ?
>> > > > > > > >
>> > > > > > > > -Matthias
>> > > > > > > >
>> > > > > > > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 
>> 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
>> > > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> >
>>
>>
> 
> 


Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Martin Marinschek <ma...@gmail.com>.
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 <zw...@gmail.com> 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 <mk...@gmail.com> 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 <zw...@gmail.com> 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 < brunoaranda@gmail.com > 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 <mk...@gmail.com> 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/%3C4499A901.2090302@rowe-clan.net%3E
> > > > >
> > > > >
> > > > >
> > > > > On 5/18/07, Manfred Geiler < manfred.geiler@gmail.com > 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 <km...@virtua.com> 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:work.grant@gmail.com]
> > > > > > > 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 < mbroekelmann@googlemail.com>
> wrote:
> > > > > > >
> > > > > > > +1 for 1.2
> > > > > > >
> > > > > > > 2007/5/18, Matthias Wessendorf < matzew@apache.org >:
> > > > > > > > So,
> > > > > > > >
> > > > > > > > any interest in making this to 2.0.0 ?
> > > > > > > >
> > > > > > > > -Matthias
> > > > > > > >
> > > > > > > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Zubin Wadia <zw...@gmail.com>.
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 <mk...@gmail.com> 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 <zw...@gmail.com> 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 <brunoaranda@gmail.com > 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 <mk...@gmail.com> 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/%3C4499A901.2090302@rowe-clan.net%3E
> > > >
> > > >
> > > >
> > > > On 5/18/07, Manfred Geiler <manfred.geiler@gmail.com > 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 <km...@virtua.com> 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:work.grant@gmail.com]
> > > > > > 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 <mb...@googlemail.com>
> wrote:
> > > > > >
> > > > > > +1 for 1.2
> > > > > >
> > > > > > 2007/5/18, Matthias Wessendorf <matzew@apache.org >:
> > > > > > > So,
> > > > > > >
> > > > > > > any interest in making this to 2.0.0 ?
> > > > > > >
> > > > > > > -Matthias
> > > > > > >
> > > > > > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
> > > > >
> > > >
> > >
> >
> >
>

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Mike Kienenberger <mk...@gmail.com>.
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 <zw...@gmail.com> 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 <brunoaranda@gmail.com > 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 <mk...@gmail.com> 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/%3C4499A901.2090302@rowe-clan.net%3E
> > >
> > >
> > >
> > > On 5/18/07, Manfred Geiler <manfred.geiler@gmail.com > 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 <km...@virtua.com> 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:work.grant@gmail.com]
> > > > > 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 <mb...@googlemail.com> wrote:
> > > > >
> > > > > +1 for 1.2
> > > > >
> > > > > 2007/5/18, Matthias Wessendorf <matzew@apache.org >:
> > > > > > So,
> > > > > >
> > > > > > any interest in making this to 2.0.0 ?
> > > > > >
> > > > > > -Matthias
> > > > > >
> > > > > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
> > > >
> > >
> >
>
>

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Zubin Wadia <zw...@gmail.com>.
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 <br...@gmail.com> 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 <mk...@gmail.com> 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/%3C4499A901.2090302@rowe-clan.net%3E
> >
> >
> >
> > On 5/18/07, Manfred Geiler <ma...@gmail.com> 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 <km...@virtua.com> 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:work.grant@gmail.com]
> > > > 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 <mb...@googlemail.com> wrote:
> > > >
> > > > +1 for 1.2
> > > >
> > > > 2007/5/18, Matthias Wessendorf <matzew@apache.org >:
> > > > > So,
> > > > >
> > > > > any interest in making this to 2.0.0 ?
> > > > >
> > > > > -Matthias
> > > > >
> > > > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
> > >
> >
>

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Bruno Aranda <br...@gmail.com>.
+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 <mk...@gmail.com> 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/%3C4499A901.2090302@rowe-clan.net%3E
>
>
>
> On 5/18/07, Manfred Geiler <ma...@gmail.com> 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 <km...@virtua.com> 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:work.grant@gmail.com]
> > > 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 <mb...@googlemail.com> wrote:
> > >
> > > +1 for 1.2
> > >
> > > 2007/5/18, Matthias Wessendorf <matzew@apache.org >:
> > > > So,
> > > >
> > > > any interest in making this to 2.0.0 ?
> > > >
> > > > -Matthias
> > > >
> > > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
> >
>

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Mike Kienenberger <mk...@gmail.com>.
+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/%3C4499A901.2090302@rowe-clan.net%3E



On 5/18/07, Manfred Geiler <ma...@gmail.com> 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 <km...@virtua.com> 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:work.grant@gmail.com]
> > 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 <mb...@googlemail.com> wrote:
> >
> > +1 for 1.2
> >
> > 2007/5/18, Matthias Wessendorf <matzew@apache.org >:
> > > So,
> > >
> > > any interest in making this to 2.0.0 ?
> > >
> > > -Matthias
> > >
> > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
>

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by David Jencks <da...@yahoo.com>.
I guess my $0.02 from the peanut gallery is that if myfaces "1.2" is  
an incremental improvement over 1.1 that doesn't have giant  
technology changes in its core but does happen to implement jsf 1.2  
then 1.2 is a more appropriate name.  If there are big core  
architectural changes so it fundamentally works differently than 1.1  
then 2.0 (or higher :-) would be more appropriate.  I have pretty  
limited exposure to myfaces but have the impression that 1.2 would be  
more in line with the extent and nature of the changes.

thanks
david jencks

On May 18, 2007, at 3:14 PM, Grant Smith wrote:

> Ugh!!
>
> I still think the benefits you mentioned do not outweigh the  
> benefit of not confusing our users :) You do make a valid point  
> regarding compatibility, but I don't see why we can't stick with  
> MyFaces 1.2.x and have all the component libs follow the same  
> version numbers ? I guess I don't fully appreciate why the "minor"  
> version number and the "fix" version number have to be separated:
>
> MyFaces 1.2.0  --> Initial JSF 1.2 compliant release.
> MyFaces 1.2.1  --> Bugfix release
> MyFaces 1.2.2  --> Some Bugs Fixed, and Included New Technology  
> that Promotes World Peace.
>
> We'll still have the "Compatibility Matrix" which states which  
> component libs are compatible, etc...
>
>
>
>
> On 5/18/07, Matthias Wessendorf <ma...@apache.org> wrote:
> thank you!
>
> On 5/18/07, Manfred Geiler <ma...@gmail.com> 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 <km...@virtua.com> 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: work.grant@gmail.com]
> > > 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 <mb...@googlemail.com>  
> wrote:
> > >
> > > +1 for 1.2
> > >
> > > 2007/5/18, Matthias Wessendorf <matzew@apache.org >:
> > > > So,
> > > >
> > > > any interest in making this to 2.0.0 ?
> > > >
> > > > -Matthias
> > > >
> > > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
>
>
> -- 
> Grant Smith


Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Grant Smith <wo...@gmail.com>.
Ugh!!

I still think the benefits you mentioned do not outweigh the benefit of not
confusing our users :) You do make a valid point regarding compatibility,
but I don't see why we can't stick with MyFaces 1.2.x and have all the
component libs follow the same version numbers ? I guess I don't fully
appreciate why the "minor" version number and the "fix" version number have
to be separated:

MyFaces 1.2.0  --> Initial JSF 1.2 compliant release.
MyFaces 1.2.1  --> Bugfix release
MyFaces 1.2.2  --> Some Bugs Fixed, and Included New Technology that
Promotes World Peace.

We'll still have the "Compatibility Matrix" which states which component
libs are compatible, etc...




On 5/18/07, Matthias Wessendorf <ma...@apache.org> wrote:
>
> thank you!
>
> On 5/18/07, Manfred Geiler <ma...@gmail.com> 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 <km...@virtua.com> 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:work.grant@gmail.com]
> > > 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 <mb...@googlemail.com> wrote:
> > >
> > > +1 for 1.2
> > >
> > > 2007/5/18, Matthias Wessendorf <matzew@apache.org >:
> > > > So,
> > > >
> > > > any interest in making this to 2.0.0 ?
> > > >
> > > > -Matthias
> > > >
> > > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>



-- 
Grant Smith

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Matthias Wessendorf <ma...@apache.org>.
thank you!

On 5/18/07, Manfred Geiler <ma...@gmail.com> 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 <km...@virtua.com> 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:work.grant@gmail.com]
> > 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 <mb...@googlemail.com> wrote:
> >
> > +1 for 1.2
> >
> > 2007/5/18, Matthias Wessendorf <matzew@apache.org >:
> > > So,
> > >
> > > any interest in making this to 2.0.0 ?
> > >
> > > -Matthias
> > >
> > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Manfred Geiler <ma...@gmail.com>.
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 <km...@virtua.com> 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:work.grant@gmail.com]
> 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 <mb...@googlemail.com> wrote:
>
> +1 for 1.2
>
> 2007/5/18, Matthias Wessendorf <matzew@apache.org >:
> > So,
> >
> > any interest in making this to 2.0.0 ?
> >
> > -Matthias
> >
> > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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

RE: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by "Kito D. Mann" <km...@virtua.com>.
+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> 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:work.grant@gmail.com] 
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 <mb...@googlemail.com> wrote: 

+1 for 1.2

2007/5/18, Matthias Wessendorf <matzew@apache.org >:
> So,
>
> any interest in making this to 2.0.0 ?
>
> -Matthias
>
> On 2/23/07, Manfred Geiler <ma...@gmail.com> 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


Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Grant Smith <wo...@gmail.com>.
+1 for 1.2
-1 for 2.0

On 5/18/07, Mathias Brökelmann <mb...@googlemail.com> wrote:
>
> +1 for 1.2
>
> 2007/5/18, Matthias Wessendorf <ma...@apache.org>:
> > So,
> >
> > any interest in making this to 2.0.0 ?
> >
> > -Matthias
> >
> > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Mathias Brökelmann <mb...@googlemail.com>.
+1 for 1.2

2007/5/18, Matthias Wessendorf <ma...@apache.org>:
> So,
>
> any interest in making this to 2.0.0 ?
>
> -Matthias
>
> On 2/23/07, Manfred Geiler <ma...@gmail.com> 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

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Matthias Wessendorf <ma...@apache.org>.
let's hope they don't call the next JSF "JSF 6" (based on Java EE 6)

But, that would mean, we can jump from 1.2 => 6.
Not to bad! :-))

-M

On 5/17/07, Simon Lessard <si...@gmail.com> wrote:
> +1 for 1.2 as well, MyFaces 2.0 for JSF 1.2 and MyFaces 3.0 for JSF 2.0
> sounds just strange to me.
>
>
> Regards,
>
> ~ Simon
>
>
> On 5/18/07, Cagatay Civici <ca...@gmail.com> wrote:
> >
> > > +1 for 1.2.
> > >
> > > IMO, Save 2.0 for JSF2.0. It's just easier to explain to non-community
> members that way and keeps it aligned with the spec releases.
> >
> >
> > +1
> >
> >
>
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Simon Lessard <si...@gmail.com>.
+1 for 1.2 as well, MyFaces 2.0 for JSF 1.2 and MyFaces 3.0 for JSF
2.0sounds just strange to me.


Regards,

~ Simon

On 5/18/07, Cagatay Civici <ca...@gmail.com> wrote:
>
> +1 for 1.2.
> >
> > IMO, Save 2.0 for JSF2.0. It's just easier to explain to non-community
> > members that way and keeps it aligned with the spec releases.
>
>
> +1
>
>
>

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Cagatay Civici <ca...@gmail.com>.
>
> +1 for 1.2.
>
> IMO, Save 2.0 for JSF2.0. It's just easier to explain to non-community
> members that way and keeps it aligned with the spec releases.


+1

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Dennis Byrne <de...@dbyrne.net>.
Whoops.  It *was* to the list.

On 5/17/07, Dennis Byrne <de...@dbyrne.net> wrote:
>
> Did you mean for that to go to the list ? :)
>
> On 5/17/07, Paul Spencer <pa...@apache.org> wrote:
> >
> > I am still +1 for
> >     JSF 1.1 -> MyFaces 1.x
> >     JSF 1.2 -> MyFaces 2.x
> >
> > Paul Spencer
> >
> > Matthias Wessendorf wrote:
> > > So,
> > >
> > > any interest in making this to 2.0.0 ?
> > >
> > > -Matthias
> > >
> > > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
> > >
> >
> >
>
>
> --
> Dennis Byrne




-- 
Dennis Byrne

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Dennis Byrne <de...@dbyrne.net>.
Did you mean for that to go to the list ? :)

On 5/17/07, Paul Spencer <pa...@apache.org> wrote:
>
> I am still +1 for
>     JSF 1.1 -> MyFaces 1.x
>     JSF 1.2 -> MyFaces 2.x
>
> Paul Spencer
>
> Matthias Wessendorf wrote:
> > So,
> >
> > any interest in making this to 2.0.0 ?
> >
> > -Matthias
> >
> > On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
> >
>
>


-- 
Dennis Byrne

Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)

Posted by Paul Spencer <pa...@apache.org>.
I am still +1 for
    JSF 1.1 -> MyFaces 1.x
    JSF 1.2 -> MyFaces 2.x

Paul Spencer

Matthias Wessendorf wrote:
> So,
> 
> any interest in making this to 2.0.0 ?
> 
> -Matthias
> 
> On 2/23/07, Manfred Geiler <ma...@gmail.com> 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
>