On Fri, Dec 18, 2009 at 1:47 PM, Ed Burns <Ed.Burns(a)sun.com> wrote:
>>>>> On Mon, 14 Dec 2009 12:33:43 -0500, Dan Allen
<dan.j.allen(a)gmail.com>
said:
EB> I've added milestones for 2.1 - 2.4. I've deleted 2.next.
DA> It was fun while it lasted (I say that jokingly because it we were
DA> having a fun play on words with JSF 2.next ;))
DA> What about 2.0.MR1? Could you add that for the errors we need to have
fixed
DA> for the MR?
As promised I went to the Sun Java EE Architects email list and asked
what was Sun's position on naming.
Thanks!
Here it is. This is the convention
Sun uses, it's not a JCP mandate.
8<------------------------------------------
We apply version numbers to all three of the JCP-defined artifacts -
specification document, reference implementation (RI), and technology
compatibility kit (TCK). At the completion of a JCP update to a
technology, all three artifacts will have the same version number, in
the single dot major.minor format.
Between JCP updates, each of these artifacts may also be updated,
following these rules:
* Specification document
Updates to a specification document that do not change the meaning
of the specification are called "errata". (See JCP Processes for
details.) An errata update to a specification document is indicated
by including a "Rev level" after the specification version number.
For example, if an initial specification numbered "1.0" is updated
by an errata, the updated document would be given a number of "1.0
Rev a". A subsequent errata update would be "1.0 Rev b".
Note that since an errata typically does not require a change to
the RI or TCK, a Rev level is never applied to those artifacts.
* Reference Implementation
A change to the RI that is not associated with a change to the API
(for example, a bug fix, performance improvement, new feature, etc.)
is indicated by using a dot-dot number of the form major.minor.micro
or a patch number of the form major.minor.micro_patch. The major and
minor numbers correspond to the version of the API that is
implemented.
To summarize...
For a spec of version X.Y, the spec document will be version "X.Y" for
the initial release or "X.Y Rev L", where "L" is a letter nominally
starting with "a" and incrementing as more errata are approved via the
JCP Maintenance Review process.
For a spec of version X.Y, the RI will be "X.Y" or "X.Y.Z", where
"Z" is
a number starting with 1 and incrementing as more RI bug fixes are
made. ("X.Y.0" should be considered equivalent to "X.Y".) These
changes
are outside the JCP process.
8<------------------------------------------
As Dan requested, I have made 2.0 Rev a the default target milestone.
As always, thanks for your detailed explanation.
Which brings me to the issue captains. I'll check the status of that
volunteer effort as a separate message.
I've been meaning to follow-up with you about that. Perhaps we can do it
first thing in 2010.
I also updated several of the issues and noticed that we could use two
additional subcomponents:
Configuration (such as faces-config.xml or web.xml)
Documentation (errors with JavaDoc, PDLDoc, etc)
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen