[jsr-314-open] [ADMIN] Target milestones in issuetracker record

[Dan Allen]

On Fri, Dec 18, 2009 at 1:47 PM, Ed Burns <Ed.Burns at sun.com> wrote:

> >>>>> On Mon, 14 Dec 2009 12:33:43 -0500, Dan Allen <dan.j.allen at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20091218/33fb5111/attachment.html