You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Manfred Geiler <ma...@apache.org> on 2007/05/25 10:31:35 UTC
[PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Hi all,
I want to get rid of that 1.2 vs. 2.0 discussion blocker. Therefore I
will try to summarize all of the arguments and collect the pros and
cons once more. The goal is to find a compromise that is acceptable
for all of us. I will try to be as impartial as possible. You will see
I'm no pigheaded person. Not always at least... ;-)
Requisites:
R1. Users (esp. non-community members) must be able to find out the
implemented spec version (JSR) easily.
R2. We must be able to distinguish bugfix releases from feature
releases (with changes or extended API).
Arguments pro 1.2.x:
A12.1. MyFaces 1.2.x is more intuitive and easier to explain to
non-community members.
A12.2. MyFaces 2.0 for JSF 1.2 and MyFaces 3.0 for JSF 2.0 sounds
strange and will confuse people.
A12.3. When the JSF 2.0 spec is out in 2008 there will by a MyFaces
2.0.x implementation which will confuse people even more.
A12.4. The JSR-252 MyFaces API lib would get the name
"myfaces-api-2.0.0.jar" (!). Mind: This is a new argument pro 1.2.x!
;-)
A12.5. MyFaces 1.2 is an incremental improvement over 1.1 that
doesn't have giant technology changes in its core.
A12.6. Tomahawk/Trinidad/Tobago are no longer tightly-coupled to a
specific MyFaces core release, and should use whatever versions make
the most sense.
A12.7. Free evolution of myfaces-impl is possible, but would come at
a cost of incompatibility with the RI.
Arguments pro 2.x.y:
A20.1. Tomcat does the same. They do not align there container
versions to the spec and nobody complains.
A20.2. Degree of freedom with minor (x) and fix (y) number. Feature
releases with changed or extended API will have a higher minor number.
Releases that only fix bugs will only count up the y number.
A20.3. Aligning the version numbers of core and component libs within
the MyFaces umbrella would be easier.
A20.4. MyFaces API can stay with a version number of 1.2, though.
A20.5. What do we do when there is a fix to the spec, i.e. JSF-1.2.1 ?
A20.6. What do we do when there is a major refactoring of MyFaces,
similar to Tomcat 5.0 and 5.5
Ok, here is my compromise proposal, which I hope everyone can live with:
C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0 which means
<major-spec-version>.<minor-spec-version>.<minor-impl-version>.<fix-version>
C2. We leave the 1.1.5 branch version numbering. Should there ever be
the need for doing a fix in that branch (security, copyright issues)
we will release a 1.1.6.
C3. Non-core libs will no longer be aligned to Core. Which means that
Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0
or 2.0.0 or any appropriate number whenever there are major feature
additions or global refactorings.
All Requistes accomplished?
R1: yes
R2: yes
Arguments?
A12.1. solved
A12.2. solved
A12.3. solved
A12.4. solved
A12.5. solved
A12.6. solved
A12.7. not constricted
A20.1. not solved. Well, MyFaces is not Tomcat...
A20.2. solved
A20.3. not solved, but identified as no longer necessary/desired
A20.4. solved
A20.5. not solved, but if there is a JSF fix we must join all our
influence and convice Ed to call it JSF-1.3 ;-)
A20.6. solved, we could switch to 1.2.5.x
Somebody mentioned that this issue is the most controversial since a
while. Well, I hope this proposal is a good compromise and we/I can
start the release procedure next week.
Regards,
Manfred
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Posted by Bruno Aranda <br...@gmail.com>.
Honestly, I think this is the best compromise we can reach. Nice job,
+1
Bruno
On 25/05/07, Werner Punz <we...@gmail.com> wrote:
> +1 to your propsal of the numbering scheme...
> The Blackdown people use something similar for their JDK Implementations.
>
>
> Manfred Geiler schrieb:
> > Hi all,
> > I want to get rid of that 1.2 vs. 2.0 discussion blocker. Therefore I
> > will try to summarize all of the arguments and collect the pros and
> > cons once more. The goal is to find a compromise that is acceptable
> > for all of us. I will try to be as impartial as possible. You will see
> > I'm no pigheaded person. Not always at least... ;-)
> >
> > Requisites:
> > R1. Users (esp. non-community members) must be able to find out the
> > implemented spec version (JSR) easily.
> > R2. We must be able to distinguish bugfix releases from feature
> > releases (with changes or extended API).
> >
> > Arguments pro 1.2.x:
> > A12.1. MyFaces 1.2.x is more intuitive and easier to explain to
> > non-community members.
> > A12.2. MyFaces 2.0 for JSF 1.2 and MyFaces 3.0 for JSF 2.0 sounds
> > strange and will confuse people.
> > A12.3. When the JSF 2.0 spec is out in 2008 there will by a MyFaces
> > 2.0.x implementation which will confuse people even more.
> > A12.4. The JSR-252 MyFaces API lib would get the name
> > "myfaces-api-2.0.0.jar" (!). Mind: This is a new argument pro 1.2.x!
> > ;-)
> > A12.5. MyFaces 1.2 is an incremental improvement over 1.1 that
> > doesn't have giant technology changes in its core.
> > A12.6. Tomahawk/Trinidad/Tobago are no longer tightly-coupled to a
> > specific MyFaces core release, and should use whatever versions make
> > the most sense.
> > A12.7. Free evolution of myfaces-impl is possible, but would come at
> > a cost of incompatibility with the RI.
> >
> > Arguments pro 2.x.y:
> > A20.1. Tomcat does the same. They do not align there container
> > versions to the spec and nobody complains.
> > A20.2. Degree of freedom with minor (x) and fix (y) number. Feature
> > releases with changed or extended API will have a higher minor number.
> > Releases that only fix bugs will only count up the y number.
> > A20.3. Aligning the version numbers of core and component libs within
> > the MyFaces umbrella would be easier.
> > A20.4. MyFaces API can stay with a version number of 1.2, though.
> > A20.5. What do we do when there is a fix to the spec, i.e. JSF-1.2.1 ?
> > A20.6. What do we do when there is a major refactoring of MyFaces,
> > similar to Tomcat 5.0 and 5.5
> >
> > Ok, here is my compromise proposal, which I hope everyone can live with:
> > C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0 which
> > means
> >
> > <major-spec-version>.<minor-spec-version>.<minor-impl-version>.<fix-version>
> >
> > C2. We leave the 1.1.5 branch version numbering. Should there ever be
> > the need for doing a fix in that branch (security, copyright issues)
> > we will release a 1.1.6.
> > C3. Non-core libs will no longer be aligned to Core. Which means that
> > Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0
> > or 2.0.0 or any appropriate number whenever there are major feature
> > additions or global refactorings.
> >
> > All Requistes accomplished?
> > R1: yes
> > R2: yes
> >
> > Arguments?
> > A12.1. solved
> > A12.2. solved
> > A12.3. solved
> > A12.4. solved
> > A12.5. solved
> > A12.6. solved
> > A12.7. not constricted
> >
> > A20.1. not solved. Well, MyFaces is not Tomcat...
> > A20.2. solved
> > A20.3. not solved, but identified as no longer necessary/desired
> > A20.4. solved
> > A20.5. not solved, but if there is a JSF fix we must join all our
> > influence and convice Ed to call it JSF-1.3 ;-)
> > A20.6. solved, we could switch to 1.2.5.x
> >
> > Somebody mentioned that this issue is the most controversial since a
> > while. Well, I hope this proposal is a good compromise and we/I can
> > start the release procedure next week.
> >
> > Regards,
> > Manfred
> >
>
>
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Posted by Werner Punz <we...@gmail.com>.
+1 to your propsal of the numbering scheme...
The Blackdown people use something similar for their JDK Implementations.
Manfred Geiler schrieb:
> Hi all,
> I want to get rid of that 1.2 vs. 2.0 discussion blocker. Therefore I
> will try to summarize all of the arguments and collect the pros and
> cons once more. The goal is to find a compromise that is acceptable
> for all of us. I will try to be as impartial as possible. You will see
> I'm no pigheaded person. Not always at least... ;-)
>
> Requisites:
> R1. Users (esp. non-community members) must be able to find out the
> implemented spec version (JSR) easily.
> R2. We must be able to distinguish bugfix releases from feature
> releases (with changes or extended API).
>
> Arguments pro 1.2.x:
> A12.1. MyFaces 1.2.x is more intuitive and easier to explain to
> non-community members.
> A12.2. MyFaces 2.0 for JSF 1.2 and MyFaces 3.0 for JSF 2.0 sounds
> strange and will confuse people.
> A12.3. When the JSF 2.0 spec is out in 2008 there will by a MyFaces
> 2.0.x implementation which will confuse people even more.
> A12.4. The JSR-252 MyFaces API lib would get the name
> "myfaces-api-2.0.0.jar" (!). Mind: This is a new argument pro 1.2.x!
> ;-)
> A12.5. MyFaces 1.2 is an incremental improvement over 1.1 that
> doesn't have giant technology changes in its core.
> A12.6. Tomahawk/Trinidad/Tobago are no longer tightly-coupled to a
> specific MyFaces core release, and should use whatever versions make
> the most sense.
> A12.7. Free evolution of myfaces-impl is possible, but would come at
> a cost of incompatibility with the RI.
>
> Arguments pro 2.x.y:
> A20.1. Tomcat does the same. They do not align there container
> versions to the spec and nobody complains.
> A20.2. Degree of freedom with minor (x) and fix (y) number. Feature
> releases with changed or extended API will have a higher minor number.
> Releases that only fix bugs will only count up the y number.
> A20.3. Aligning the version numbers of core and component libs within
> the MyFaces umbrella would be easier.
> A20.4. MyFaces API can stay with a version number of 1.2, though.
> A20.5. What do we do when there is a fix to the spec, i.e. JSF-1.2.1 ?
> A20.6. What do we do when there is a major refactoring of MyFaces,
> similar to Tomcat 5.0 and 5.5
>
> Ok, here is my compromise proposal, which I hope everyone can live with:
> C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0 which
> means
>
> <major-spec-version>.<minor-spec-version>.<minor-impl-version>.<fix-version>
>
> C2. We leave the 1.1.5 branch version numbering. Should there ever be
> the need for doing a fix in that branch (security, copyright issues)
> we will release a 1.1.6.
> C3. Non-core libs will no longer be aligned to Core. Which means that
> Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0
> or 2.0.0 or any appropriate number whenever there are major feature
> additions or global refactorings.
>
> All Requistes accomplished?
> R1: yes
> R2: yes
>
> Arguments?
> A12.1. solved
> A12.2. solved
> A12.3. solved
> A12.4. solved
> A12.5. solved
> A12.6. solved
> A12.7. not constricted
>
> A20.1. not solved. Well, MyFaces is not Tomcat...
> A20.2. solved
> A20.3. not solved, but identified as no longer necessary/desired
> A20.4. solved
> A20.5. not solved, but if there is a JSF fix we must join all our
> influence and convice Ed to call it JSF-1.3 ;-)
> A20.6. solved, we could switch to 1.2.5.x
>
> Somebody mentioned that this issue is the most controversial since a
> while. Well, I hope this proposal is a good compromise and we/I can
> start the release procedure next week.
>
> Regards,
> Manfred
>
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Posted by Martin Marinschek <ma...@gmail.com>.
I can live with that!
regards,
Martin
On 5/25/07, Bruno Aranda <br...@gmail.com> wrote:
> On 25/05/07, Jesse Alexander (KSFD 121)
> <al...@credit-suisse.com> wrote:
> > sounds good... and the 4-number version mirrors somewhat the RI, they
>
> ...
>
> > But I would not expect official spec-releases other than the
> > JSF-nextGeneration spec (JSF 2.0 or JSF6, I fear the latter still has
> > its lobby).
>
> I guess it is safe to talk about that one as JSR-314, just in case...
>
> Bruno
>
> >
> > regards
> > Alexander
> >
> > -----Original Message-----
> > From: manfred.geiler@gmail.com [mailto:manfred.geiler@gmail.com] On
> > Behalf Of Manfred Geiler
> > Sent: Friday, May 25, 2007 10:32 AM
> > To: MyFaces Development
> > Subject: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
> >
> > Hi all,
> > I want to get rid of that 1.2 vs. 2.0 discussion blocker. Therefore I
> > will try to summarize all of the arguments and collect the pros and
> > cons once more. The goal is to find a compromise that is acceptable
> > for all of us. I will try to be as impartial as possible. You will see
> > I'm no pigheaded person. Not always at least... ;-)
> >
> > Requisites:
> > R1. Users (esp. non-community members) must be able to find out the
> > implemented spec version (JSR) easily.
> > R2. We must be able to distinguish bugfix releases from feature
> > releases (with changes or extended API).
> >
> > Arguments pro 1.2.x:
> > A12.1. MyFaces 1.2.x is more intuitive and easier to explain to
> > non-community members.
> > A12.2. MyFaces 2.0 for JSF 1.2 and MyFaces 3.0 for JSF 2.0 sounds
> > strange and will confuse people.
> > A12.3. When the JSF 2.0 spec is out in 2008 there will by a MyFaces
> > 2.0.x implementation which will confuse people even more.
> > A12.4. The JSR-252 MyFaces API lib would get the name
> > "myfaces-api-2.0.0.jar" (!). Mind: This is a new argument pro 1.2.x!
> > ;-)
> > A12.5. MyFaces 1.2 is an incremental improvement over 1.1 that
> > doesn't have giant technology changes in its core.
> > A12.6. Tomahawk/Trinidad/Tobago are no longer tightly-coupled to a
> > specific MyFaces core release, and should use whatever versions make
> > the most sense.
> > A12.7. Free evolution of myfaces-impl is possible, but would come at
> > a cost of incompatibility with the RI.
> >
> > Arguments pro 2.x.y:
> > A20.1. Tomcat does the same. They do not align there container
> > versions to the spec and nobody complains.
> > A20.2. Degree of freedom with minor (x) and fix (y) number. Feature
> > releases with changed or extended API will have a higher minor number.
> > Releases that only fix bugs will only count up the y number.
> > A20.3. Aligning the version numbers of core and component libs within
> > the MyFaces umbrella would be easier.
> > A20.4. MyFaces API can stay with a version number of 1.2, though.
> > A20.5. What do we do when there is a fix to the spec, i.e. JSF-1.2.1 ?
> > A20.6. What do we do when there is a major refactoring of MyFaces,
> > similar to Tomcat 5.0 and 5.5
> >
> > Ok, here is my compromise proposal, which I hope everyone can live with:
> > C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0
> > which means
> >
> > <major-spec-version>.<minor-spec-version>.<minor-impl-version>.<fix-vers
> > ion>
> > C2. We leave the 1.1.5 branch version numbering. Should there ever be
> > the need for doing a fix in that branch (security, copyright issues)
> > we will release a 1.1.6.
> > C3. Non-core libs will no longer be aligned to Core. Which means that
> > Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0
> > or 2.0.0 or any appropriate number whenever there are major feature
> > additions or global refactorings.
> >
> > All Requistes accomplished?
> > R1: yes
> > R2: yes
> >
> > Arguments?
> > A12.1. solved
> > A12.2. solved
> > A12.3. solved
> > A12.4. solved
> > A12.5. solved
> > A12.6. solved
> > A12.7. not constricted
> >
> > A20.1. not solved. Well, MyFaces is not Tomcat...
> > A20.2. solved
> > A20.3. not solved, but identified as no longer necessary/desired
> > A20.4. solved
> > A20.5. not solved, but if there is a JSF fix we must join all our
> > influence and convice Ed to call it JSF-1.3 ;-)
> > A20.6. solved, we could switch to 1.2.5.x
> >
> > Somebody mentioned that this issue is the most controversial since a
> > while. Well, I hope this proposal is a good compromise and we/I can
> > start the release procedure next week.
> >
> > Regards,
> > Manfred
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Posted by Bruno Aranda <br...@gmail.com>.
On 25/05/07, Jesse Alexander (KSFD 121)
<al...@credit-suisse.com> wrote:
> sounds good... and the 4-number version mirrors somewhat the RI, they
...
> But I would not expect official spec-releases other than the
> JSF-nextGeneration spec (JSF 2.0 or JSF6, I fear the latter still has
> its lobby).
I guess it is safe to talk about that one as JSR-314, just in case...
Bruno
>
> regards
> Alexander
>
> -----Original Message-----
> From: manfred.geiler@gmail.com [mailto:manfred.geiler@gmail.com] On
> Behalf Of Manfred Geiler
> Sent: Friday, May 25, 2007 10:32 AM
> To: MyFaces Development
> Subject: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
>
> Hi all,
> I want to get rid of that 1.2 vs. 2.0 discussion blocker. Therefore I
> will try to summarize all of the arguments and collect the pros and
> cons once more. The goal is to find a compromise that is acceptable
> for all of us. I will try to be as impartial as possible. You will see
> I'm no pigheaded person. Not always at least... ;-)
>
> Requisites:
> R1. Users (esp. non-community members) must be able to find out the
> implemented spec version (JSR) easily.
> R2. We must be able to distinguish bugfix releases from feature
> releases (with changes or extended API).
>
> Arguments pro 1.2.x:
> A12.1. MyFaces 1.2.x is more intuitive and easier to explain to
> non-community members.
> A12.2. MyFaces 2.0 for JSF 1.2 and MyFaces 3.0 for JSF 2.0 sounds
> strange and will confuse people.
> A12.3. When the JSF 2.0 spec is out in 2008 there will by a MyFaces
> 2.0.x implementation which will confuse people even more.
> A12.4. The JSR-252 MyFaces API lib would get the name
> "myfaces-api-2.0.0.jar" (!). Mind: This is a new argument pro 1.2.x!
> ;-)
> A12.5. MyFaces 1.2 is an incremental improvement over 1.1 that
> doesn't have giant technology changes in its core.
> A12.6. Tomahawk/Trinidad/Tobago are no longer tightly-coupled to a
> specific MyFaces core release, and should use whatever versions make
> the most sense.
> A12.7. Free evolution of myfaces-impl is possible, but would come at
> a cost of incompatibility with the RI.
>
> Arguments pro 2.x.y:
> A20.1. Tomcat does the same. They do not align there container
> versions to the spec and nobody complains.
> A20.2. Degree of freedom with minor (x) and fix (y) number. Feature
> releases with changed or extended API will have a higher minor number.
> Releases that only fix bugs will only count up the y number.
> A20.3. Aligning the version numbers of core and component libs within
> the MyFaces umbrella would be easier.
> A20.4. MyFaces API can stay with a version number of 1.2, though.
> A20.5. What do we do when there is a fix to the spec, i.e. JSF-1.2.1 ?
> A20.6. What do we do when there is a major refactoring of MyFaces,
> similar to Tomcat 5.0 and 5.5
>
> Ok, here is my compromise proposal, which I hope everyone can live with:
> C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0
> which means
>
> <major-spec-version>.<minor-spec-version>.<minor-impl-version>.<fix-vers
> ion>
> C2. We leave the 1.1.5 branch version numbering. Should there ever be
> the need for doing a fix in that branch (security, copyright issues)
> we will release a 1.1.6.
> C3. Non-core libs will no longer be aligned to Core. Which means that
> Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0
> or 2.0.0 or any appropriate number whenever there are major feature
> additions or global refactorings.
>
> All Requistes accomplished?
> R1: yes
> R2: yes
>
> Arguments?
> A12.1. solved
> A12.2. solved
> A12.3. solved
> A12.4. solved
> A12.5. solved
> A12.6. solved
> A12.7. not constricted
>
> A20.1. not solved. Well, MyFaces is not Tomcat...
> A20.2. solved
> A20.3. not solved, but identified as no longer necessary/desired
> A20.4. solved
> A20.5. not solved, but if there is a JSF fix we must join all our
> influence and convice Ed to call it JSF-1.3 ;-)
> A20.6. solved, we could switch to 1.2.5.x
>
> Somebody mentioned that this issue is the most controversial since a
> while. Well, I hope this proposal is a good compromise and we/I can
> start the release procedure next week.
>
> Regards,
> Manfred
>
RE: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Posted by "Jesse Alexander (KSFD 121)" <al...@credit-suisse.com>.
sounds good... and the 4-number version mirrors somewhat the RI, they
are at
1.2_04P02
so +1 (non-binding from me)
> A20.1. not solved. Well, MyFaces is not Tomcat...
It is something confusing with Tomcat... one has to search the ewb to
know which servlet-spec
correlates to which tomcat... so MyFaces improves in this area!
> A20.5. not solved, but if there is a JSF fix we must join all our
> influence and convice Ed to call it JSF-1.3 ;-)
I would say a bug-fix release of the spec is not important enough to be
reflected into the version number of MyFaces. If necessary it will
prompt a new impl-minor number to comply...
And the discussion about the spec-version usually is held on ##jsf. And
some MyFaces-fans are
there present. Bruno and Wendy, every now and then show up... and I'm a
regular
>> A20.5. not solved, but if there is a JSF fix we must join all our
>> influence and convice Ed to call it JSF-1.3 ;-)
>This only happens if there is a minor release of the spec .... do we
>have seen something in the past?
No, but it has been discussed already once. ;) An argument for having
bug-versions of the
spec is the deployment in big corporations which are (usually) very
change-unfriendly. So
developers have more problems to slip in a new version complying to a
new minor of the
spec than "being forced to apply the version because of identified
bugs"...
But I would not expect official spec-releases other than the
JSF-nextGeneration spec (JSF 2.0 or JSF6, I fear the latter still has
its lobby).
regards
Alexander
-----Original Message-----
From: manfred.geiler@gmail.com [mailto:manfred.geiler@gmail.com] On
Behalf Of Manfred Geiler
Sent: Friday, May 25, 2007 10:32 AM
To: MyFaces Development
Subject: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Hi all,
I want to get rid of that 1.2 vs. 2.0 discussion blocker. Therefore I
will try to summarize all of the arguments and collect the pros and
cons once more. The goal is to find a compromise that is acceptable
for all of us. I will try to be as impartial as possible. You will see
I'm no pigheaded person. Not always at least... ;-)
Requisites:
R1. Users (esp. non-community members) must be able to find out the
implemented spec version (JSR) easily.
R2. We must be able to distinguish bugfix releases from feature
releases (with changes or extended API).
Arguments pro 1.2.x:
A12.1. MyFaces 1.2.x is more intuitive and easier to explain to
non-community members.
A12.2. MyFaces 2.0 for JSF 1.2 and MyFaces 3.0 for JSF 2.0 sounds
strange and will confuse people.
A12.3. When the JSF 2.0 spec is out in 2008 there will by a MyFaces
2.0.x implementation which will confuse people even more.
A12.4. The JSR-252 MyFaces API lib would get the name
"myfaces-api-2.0.0.jar" (!). Mind: This is a new argument pro 1.2.x!
;-)
A12.5. MyFaces 1.2 is an incremental improvement over 1.1 that
doesn't have giant technology changes in its core.
A12.6. Tomahawk/Trinidad/Tobago are no longer tightly-coupled to a
specific MyFaces core release, and should use whatever versions make
the most sense.
A12.7. Free evolution of myfaces-impl is possible, but would come at
a cost of incompatibility with the RI.
Arguments pro 2.x.y:
A20.1. Tomcat does the same. They do not align there container
versions to the spec and nobody complains.
A20.2. Degree of freedom with minor (x) and fix (y) number. Feature
releases with changed or extended API will have a higher minor number.
Releases that only fix bugs will only count up the y number.
A20.3. Aligning the version numbers of core and component libs within
the MyFaces umbrella would be easier.
A20.4. MyFaces API can stay with a version number of 1.2, though.
A20.5. What do we do when there is a fix to the spec, i.e. JSF-1.2.1 ?
A20.6. What do we do when there is a major refactoring of MyFaces,
similar to Tomcat 5.0 and 5.5
Ok, here is my compromise proposal, which I hope everyone can live with:
C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0
which means
<major-spec-version>.<minor-spec-version>.<minor-impl-version>.<fix-vers
ion>
C2. We leave the 1.1.5 branch version numbering. Should there ever be
the need for doing a fix in that branch (security, copyright issues)
we will release a 1.1.6.
C3. Non-core libs will no longer be aligned to Core. Which means that
Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0
or 2.0.0 or any appropriate number whenever there are major feature
additions or global refactorings.
All Requistes accomplished?
R1: yes
R2: yes
Arguments?
A12.1. solved
A12.2. solved
A12.3. solved
A12.4. solved
A12.5. solved
A12.6. solved
A12.7. not constricted
A20.1. not solved. Well, MyFaces is not Tomcat...
A20.2. solved
A20.3. not solved, but identified as no longer necessary/desired
A20.4. solved
A20.5. not solved, but if there is a JSF fix we must join all our
influence and convice Ed to call it JSF-1.3 ;-)
A20.6. solved, we could switch to 1.2.5.x
Somebody mentioned that this issue is the most controversial since a
while. Well, I hope this proposal is a good compromise and we/I can
start the release procedure next week.
Regards,
Manfred
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Posted by Paul McMahan <pa...@gmail.com>.
On May 25, 2007, at 4:31 AM, Manfred Geiler wrote:
> Arguments pro 2.x.y:
> A20.1. Tomcat does the same. They do not align there container
> versions to the spec and nobody complains.
This is an excellent proposal and clearly takes all the factors we
have discussed into account. I would have no hesitation in
supporting this approach.
Since Tomcat's approach has factored into this proposal I would feel
remiss if I did not at least mention one other alternative that is in
use at ASF today by the Geronimo project. I don't necessarily mean
to imply that Geronimo's approach is better than Manfred's proposal
or that it even addresses all the issues our discussion has
identified. But I think that for the sake of consistency across ASF
that there is merit in at least giving it a moment of consideration.
As an implementer of many different Java EE specs[1] the Geronimo
project has contended with this issue of using spec vs. release
version. Adding some further complication is that fact that each
spec is released and maintained independently from each other and
from Geronimo's core application server. The current approach
Geronimo takes is to use *both* version numbers, making the spec
version part of the artifact name, and assigning the release version
independently of the spec version. This topic is frequently
discussed by the Geronimo team. See [2] and [3] below for
background, including some feedback from the Maven team.
For example, using this approach Geronimo has released four versions
of the JavaMail 1.3.1 specification. The pom.xml for the first
version looks like this:
<artifactId>geronimo-javamail_1.3.1_spec</artifactId>
<version>1.0</version>
the second like this, and so on:
<artifactId>geronimo-javamail_1.3.1_spec</artifactId>
<version>1.1</version>
Maven produces jar names like this:
geronimo-javamail_1.3.1_spec-1.0.jar
This approach has not been without its detractors. But it has some
advantages, two of the most important being that for release
management you can account for both spec and release versioning
simultaneously, and users can tell the spec and release version by
looking at the jar. It has also proven to work fine with Maven
(version ranges, dependency resolution, etc), and the Maven team has
been actively working with Geronimo to develop and improve the
tooling to support this approach [4].
Like I said, I don't mean to derail Manfred's excellent proposal
which I think could in fact work better for MyFaces in the end. The
main reason I bring this additional information to light is because
while MyFaces is for all practical purposes an autonomous project I
agree with Manfred that for the sake of consistency we should take
what other ASF projects are doing into consideration.
Best wishes,
Paul
[1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
[2] http://tinyurl.com/3yqmzs
[3] http://tinyurl.com/yqu6cn
[4] http://tinyurl.com/yur73u
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Posted by Simon Lessard <si...@gmail.com>.
+1
On 5/25/07, Zubin Wadia <zw...@gmail.com> wrote:
>
> +1, great mediation Manfred.
>
> Cheers,
>
> Zubin.
>
> On 5/25/07, Manfred Geiler <ma...@apache.org> wrote:
> >
> > Hi all,
> > I want to get rid of that 1.2 vs. 2.0 discussion blocker. Therefore I
> > will try to summarize all of the arguments and collect the pros and
> > cons once more. The goal is to find a compromise that is acceptable
> > for all of us. I will try to be as impartial as possible. You will see
> > I'm no pigheaded person. Not always at least... ;-)
> >
> > Requisites:
> > R1. Users (esp. non-community members) must be able to find out the
> > implemented spec version (JSR) easily.
> > R2. We must be able to distinguish bugfix releases from feature
> > releases (with changes or extended API).
> >
> > Arguments pro 1.2.x:
> > A12.1. MyFaces 1.2.x is more intuitive and easier to explain to
> > non-community members.
> > A12.2. MyFaces 2.0 for JSF 1.2 and MyFaces 3.0 for JSF 2.0 sounds
> > strange and will confuse people.
> > A12.3. When the JSF 2.0 spec is out in 2008 there will by a MyFaces
> > 2.0.x implementation which will confuse people even more.
> > A12.4. The JSR-252 MyFaces API lib would get the name
> > "myfaces-api-2.0.0.jar " (!). Mind: This is a new argument pro 1.2.x!
> > ;-)
> > A12.5. MyFaces 1.2 is an incremental improvement over 1.1 that
> > doesn't have giant technology changes in its core.
> > A12.6. Tomahawk/Trinidad/Tobago are no longer tightly-coupled to a
> > specific MyFaces core release, and should use whatever versions make
> > the most sense.
> > A12.7. Free evolution of myfaces-impl is possible, but would come at
> > a cost of incompatibility with the RI.
> >
> > Arguments pro 2.x.y:
> > A20.1. Tomcat does the same. They do not align there container
> > versions to the spec and nobody complains.
> > A20.2. Degree of freedom with minor (x) and fix (y) number. Feature
> > releases with changed or extended API will have a higher minor number.
> > Releases that only fix bugs will only count up the y number.
> > A20.3. Aligning the version numbers of core and component libs within
> > the MyFaces umbrella would be easier.
> > A20.4. MyFaces API can stay with a version number of 1.2, though.
> > A20.5. What do we do when there is a fix to the spec, i.e. JSF-1.2.1 ?
> > A20.6. What do we do when there is a major refactoring of MyFaces,
> > similar to Tomcat 5.0 and 5.5
> >
> > Ok, here is my compromise proposal, which I hope everyone can live with:
> >
> > C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0 which
> > means
> > <major-spec-version>.<minor-spec-version>.<minor-impl-version>.<fix-version>
> >
> > C2. We leave the 1.1.5 branch version numbering. Should there ever be
> > the need for doing a fix in that branch (security, copyright issues)
> > we will release a 1.1.6.
> > C3. Non-core libs will no longer be aligned to Core. Which means that
> > Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0
> > or 2.0.0 or any appropriate number whenever there are major feature
> > additions or global refactorings.
> >
> > All Requistes accomplished?
> > R1: yes
> > R2: yes
> >
> > Arguments?
> > A12.1. solved
> > A12.2. solved
> > A12.3. solved
> > A12.4. solved
> > A12.5. solved
> > A12.6. solved
> > A12.7. not constricted
> >
> > A20.1. not solved. Well, MyFaces is not Tomcat...
> > A20.2. solved
> > A20.3. not solved, but identified as no longer necessary/desired
> > A20.4. solved
> > A20.5. not solved, but if there is a JSF fix we must join all our
> > influence and convice Ed to call it JSF-1.3 ;-)
> > A20.6. solved, we could switch to 1.2.5.x
> >
> > Somebody mentioned that this issue is the most controversial since a
> > while. Well, I hope this proposal is a good compromise and we/I can
> > start the release procedure next week.
> >
> > Regards,
> > Manfred
> >
>
>
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Posted by Zubin Wadia <zw...@gmail.com>.
+1, great mediation Manfred.
Cheers,
Zubin.
On 5/25/07, Manfred Geiler <ma...@apache.org> wrote:
>
> Hi all,
> I want to get rid of that 1.2 vs. 2.0 discussion blocker. Therefore I
> will try to summarize all of the arguments and collect the pros and
> cons once more. The goal is to find a compromise that is acceptable
> for all of us. I will try to be as impartial as possible. You will see
> I'm no pigheaded person. Not always at least... ;-)
>
> Requisites:
> R1. Users (esp. non-community members) must be able to find out the
> implemented spec version (JSR) easily.
> R2. We must be able to distinguish bugfix releases from feature
> releases (with changes or extended API).
>
> Arguments pro 1.2.x:
> A12.1. MyFaces 1.2.x is more intuitive and easier to explain to
> non-community members.
> A12.2. MyFaces 2.0 for JSF 1.2 and MyFaces 3.0 for JSF 2.0 sounds
> strange and will confuse people.
> A12.3. When the JSF 2.0 spec is out in 2008 there will by a MyFaces
> 2.0.x implementation which will confuse people even more.
> A12.4. The JSR-252 MyFaces API lib would get the name
> "myfaces-api-2.0.0.jar" (!). Mind: This is a new argument pro 1.2.x!
> ;-)
> A12.5. MyFaces 1.2 is an incremental improvement over 1.1 that
> doesn't have giant technology changes in its core.
> A12.6. Tomahawk/Trinidad/Tobago are no longer tightly-coupled to a
> specific MyFaces core release, and should use whatever versions make
> the most sense.
> A12.7. Free evolution of myfaces-impl is possible, but would come at
> a cost of incompatibility with the RI.
>
> Arguments pro 2.x.y:
> A20.1. Tomcat does the same. They do not align there container
> versions to the spec and nobody complains.
> A20.2. Degree of freedom with minor (x) and fix (y) number. Feature
> releases with changed or extended API will have a higher minor number.
> Releases that only fix bugs will only count up the y number.
> A20.3. Aligning the version numbers of core and component libs within
> the MyFaces umbrella would be easier.
> A20.4. MyFaces API can stay with a version number of 1.2, though.
> A20.5. What do we do when there is a fix to the spec, i.e. JSF-1.2.1 ?
> A20.6. What do we do when there is a major refactoring of MyFaces,
> similar to Tomcat 5.0 and 5.5
>
> Ok, here is my compromise proposal, which I hope everyone can live with:
> C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0 which
> means
>
> <major-spec-version>.<minor-spec-version>.<minor-impl-version>.<fix-version>
> C2. We leave the 1.1.5 branch version numbering. Should there ever be
> the need for doing a fix in that branch (security, copyright issues)
> we will release a 1.1.6.
> C3. Non-core libs will no longer be aligned to Core. Which means that
> Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0
> or 2.0.0 or any appropriate number whenever there are major feature
> additions or global refactorings.
>
> All Requistes accomplished?
> R1: yes
> R2: yes
>
> Arguments?
> A12.1. solved
> A12.2. solved
> A12.3. solved
> A12.4. solved
> A12.5. solved
> A12.6. solved
> A12.7. not constricted
>
> A20.1. not solved. Well, MyFaces is not Tomcat...
> A20.2. solved
> A20.3. not solved, but identified as no longer necessary/desired
> A20.4. solved
> A20.5. not solved, but if there is a JSF fix we must join all our
> influence and convice Ed to call it JSF-1.3 ;-)
> A20.6. solved, we could switch to 1.2.5.x
>
> Somebody mentioned that this issue is the most controversial since a
> while. Well, I hope this proposal is a good compromise and we/I can
> start the release procedure next week.
>
> Regards,
> Manfred
>
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Posted by Mike Kienenberger <mk...@gmail.com>.
+1 to MyFaces Core 1.2.x.y for the JSF 1.2 implementation name.
On 5/25/07, Manfred Geiler <ma...@apache.org> wrote:
> Hi all,
> I want to get rid of that 1.2 vs. 2.0 discussion blocker. Therefore I
> will try to summarize all of the arguments and collect the pros and
> cons once more. The goal is to find a compromise that is acceptable
> for all of us. I will try to be as impartial as possible. You will see
> I'm no pigheaded person. Not always at least... ;-)
>
> Requisites:
> R1. Users (esp. non-community members) must be able to find out the
> implemented spec version (JSR) easily.
> R2. We must be able to distinguish bugfix releases from feature
> releases (with changes or extended API).
>
> Arguments pro 1.2.x:
> A12.1. MyFaces 1.2.x is more intuitive and easier to explain to
> non-community members.
> A12.2. MyFaces 2.0 for JSF 1.2 and MyFaces 3.0 for JSF 2.0 sounds
> strange and will confuse people.
> A12.3. When the JSF 2.0 spec is out in 2008 there will by a MyFaces
> 2.0.x implementation which will confuse people even more.
> A12.4. The JSR-252 MyFaces API lib would get the name
> "myfaces-api-2.0.0.jar" (!). Mind: This is a new argument pro 1.2.x!
> ;-)
> A12.5. MyFaces 1.2 is an incremental improvement over 1.1 that
> doesn't have giant technology changes in its core.
> A12.6. Tomahawk/Trinidad/Tobago are no longer tightly-coupled to a
> specific MyFaces core release, and should use whatever versions make
> the most sense.
> A12.7. Free evolution of myfaces-impl is possible, but would come at
> a cost of incompatibility with the RI.
>
> Arguments pro 2.x.y:
> A20.1. Tomcat does the same. They do not align there container
> versions to the spec and nobody complains.
> A20.2. Degree of freedom with minor (x) and fix (y) number. Feature
> releases with changed or extended API will have a higher minor number.
> Releases that only fix bugs will only count up the y number.
> A20.3. Aligning the version numbers of core and component libs within
> the MyFaces umbrella would be easier.
> A20.4. MyFaces API can stay with a version number of 1.2, though.
> A20.5. What do we do when there is a fix to the spec, i.e. JSF-1.2.1 ?
> A20.6. What do we do when there is a major refactoring of MyFaces,
> similar to Tomcat 5.0 and 5.5
>
> Ok, here is my compromise proposal, which I hope everyone can live with:
> C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0 which means
> <major-spec-version>.<minor-spec-version>.<minor-impl-version>.<fix-version>
> C2. We leave the 1.1.5 branch version numbering. Should there ever be
> the need for doing a fix in that branch (security, copyright issues)
> we will release a 1.1.6.
> C3. Non-core libs will no longer be aligned to Core. Which means that
> Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0
> or 2.0.0 or any appropriate number whenever there are major feature
> additions or global refactorings.
>
> All Requistes accomplished?
> R1: yes
> R2: yes
>
> Arguments?
> A12.1. solved
> A12.2. solved
> A12.3. solved
> A12.4. solved
> A12.5. solved
> A12.6. solved
> A12.7. not constricted
>
> A20.1. not solved. Well, MyFaces is not Tomcat...
> A20.2. solved
> A20.3. not solved, but identified as no longer necessary/desired
> A20.4. solved
> A20.5. not solved, but if there is a JSF fix we must join all our
> influence and convice Ed to call it JSF-1.3 ;-)
> A20.6. solved, we could switch to 1.2.5.x
>
> Somebody mentioned that this issue is the most controversial since a
> while. Well, I hope this proposal is a good compromise and we/I can
> start the release procedure next week.
>
> Regards,
> Manfred
>
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Posted by Paul Spencer <pa...@apache.org>.
Manfred,
+1 for the Proposal.
Once the proposal is accepted, please post a proposal for the next version number
for each affected sub project. I would posts one now for Tomahawk, but I do not
want to distract anyone.
Paul Spencer
Manfred Geiler wrote:
> see inline
>
> On 5/25/07, Paul Spencer <pa...@apache.org> wrote:
>
>> Manfred,
>>
>> Thank you for this! Below are a couple questions.
>>
>> Manfred Geiler wrote:
>> > Hi all,
>> <snip>
>> >
>> > Ok, here is my compromise proposal, which I hope everyone can live
>> with:
>> > C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0
>> which
>> > means
>> >
>> >
>> <major-spec-version>.<minor-spec-version>.<minor-impl-version>.<fix-version>
>>
>> >
>>
>> Is this supported by Maven?
>
>
> yes
>
>
>> <snip>
>> > C3. Non-core libs will no longer be aligned to Core. Which means that
>> > Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0
>> > or 2.0.0 or any appropriate number whenever there are major feature
>> > additions or global refactorings.
>>
>> 1) Although it is inferred, should the version number be in the form?
>> <major-spec-version>.<minor-spec-version>.<fix-version> ([
>> -<qualifier> ] | [ -<build> ])
>>
>> 2) Should this proposal include the next version number for the
>> mention projects?
>
>
> This proposal was meant to define the versioning scheme for MyFaces
> Core AND at the same time decouple all other libs
> (Tomahawk,Trinidad,Tobago,Shared, etc.) from the core version numbers.
> IMO the next version numbers and the future versioning schemes for the
> component libs should be discussed for each sub-project separately.
>
>
>
>> <snip>
>> >
>> > Somebody mentioned that this issue is the most controversial since a
>> > while. Well, I hope this proposal is a good compromise and we/I can
>> > start the release procedure next week.
>> >
>> > Regards,
>> > Manfred
>> >
>> >
>>
>> In short I support the compromise.
>
>
> Thanks!
>
> --Manfred
>
>
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Posted by Manfred Geiler <ma...@gmail.com>.
see inline
On 5/25/07, Paul Spencer <pa...@apache.org> wrote:
> Manfred,
>
> Thank you for this! Below are a couple questions.
>
> Manfred Geiler wrote:
> > Hi all,
> <snip>
> >
> > Ok, here is my compromise proposal, which I hope everyone can live with:
> > C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0 which
> > means
> >
> > <major-spec-version>.<minor-spec-version>.<minor-impl-version>.<fix-version>
> >
>
> Is this supported by Maven?
yes
> <snip>
> > C3. Non-core libs will no longer be aligned to Core. Which means that
> > Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0
> > or 2.0.0 or any appropriate number whenever there are major feature
> > additions or global refactorings.
>
> 1) Although it is inferred, should the version number be in the form?
> <major-spec-version>.<minor-spec-version>.<fix-version> ([ -<qualifier> ] | [ -<build> ])
>
> 2) Should this proposal include the next version number for the mention projects?
This proposal was meant to define the versioning scheme for MyFaces
Core AND at the same time decouple all other libs
(Tomahawk,Trinidad,Tobago,Shared, etc.) from the core version numbers.
IMO the next version numbers and the future versioning schemes for the
component libs should be discussed for each sub-project separately.
> <snip>
> >
> > Somebody mentioned that this issue is the most controversial since a
> > while. Well, I hope this proposal is a good compromise and we/I can
> > start the release procedure next week.
> >
> > Regards,
> > Manfred
> >
> >
>
> In short I support the compromise.
Thanks!
--Manfred
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Posted by Paul Spencer <pa...@apache.org>.
Manfred,
Thank you for this! Below are a couple questions.
Manfred Geiler wrote:
> Hi all,
<snip>
>
> Ok, here is my compromise proposal, which I hope everyone can live with:
> C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0 which
> means
>
> <major-spec-version>.<minor-spec-version>.<minor-impl-version>.<fix-version>
>
Is this supported by Maven?
>
<snip>
> C3. Non-core libs will no longer be aligned to Core. Which means that
> Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0
> or 2.0.0 or any appropriate number whenever there are major feature
> additions or global refactorings.
1) Although it is inferred, should the version number be in the form?
<major-spec-version>.<minor-spec-version>.<fix-version> ([ -<qualifier> ] | [ -<build> ])
2) Should this proposal include the next version number for the mention projects?
>
<snip>
>
> Somebody mentioned that this issue is the most controversial since a
> while. Well, I hope this proposal is a good compromise and we/I can
> start the release procedure next week.
>
> Regards,
> Manfred
>
>
In short I support the compromise.
Again, Thank you.
Paul Spencer
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Manfred!
For me, all in your post result in a simple +1 from my side ;-)
> A20.5. not solved, but if there is a JSF fix we must join all our
> influence and convice Ed to call it JSF-1.3 ;-)
This only happens if there is a minor release of the spec .... do we
have seen something in the past?
Ciao,
Mario