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