[Jakarta-commons Wiki] Update of "id/1.0ReleasePlan" by JörgSchaible

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification.

The following page has been changed by JörgSchaible:
http://wiki.apache.org/jakarta-commons/id/1%2e0ReleasePlan

The comment on the change is:
Summary of the release plan for commons-id 1.0 as already discussed on the list.

New page:
= Release Plan For Commons Id 1.0 =

== Background ==

Commons-Id exists now for several years in TheSandbox of Jakarta Commons and has now attracted some developers to build a community, that can maintain the component and it has substantial implementations for various useful identifier generators. Since 1.0 is the first official release, some changes can still be rather drastic to ensure the longevity of the released API.

== Status ==

Planning stage - straw man.

----

= Pre Release Tasks =

== Coding ==

 * Review UUID implementation and verify the spec compliance [[http://www.ietf.org/rfc/rfc4122.txt RFC 4122]]
  * Verify spec compliance
  * Check against JDK 1.5 functionality
  * Introduce a UUIDIdentifierGenerator interface extending StringIdentifierGenerator with extended functionality to get the identifier directly as UUID or additionally as byte array.
  * Review the internal plugin mechanism
  * Fix persistent store of State (ensure usability in system class path and application class path)
 * Drop IdentifierGeneratorFactory and IdentifierUtils
  This elements used static versions of each available IdentifierGenrator implementation and parametrization to provide a convenient way to access the generators available in commons-id. With the addition of new generator implementations the convenience for users vanish in combination with the maintainability.
 * Refactor PrefixXXXGeneratorIdentifier implementations
  It might be useful for all String-based generators to decorate the created identifier. The 3 current prefix implementations should be replaced by a generic decorator or transformator approach.
 * Introduce a Wrappable interface for serial generators that may wrap
  Most implementations of serial identifier generators currently support a flag ''wrap'', that enables the generator to start over with the sequence of identifiers if the generation maximum is reached. The interface should be introduced to unify the access to this flag.
 * Hide copied code from commons-codec
  To prevent a dependency on commons-codec two utility classes (DigestUtils and Hex) were copied along with two exceptions (EncoderException and DecoderException) into commons-id. These classes are now located very prominent in the o.a.c.id top level package and are currently part of the official API. Best solution would be to have them package scope or put them at least into a package o.a.c.id.internal.
 * Make GeneratorIdentifier implementations serializable
  Most of the generator implementations could be made serializable without any problem. Serialization should be ensured by appropriate unit tests though. The serializable implementation should also support a serialVersionUID. We might either use just 1L or the date we added this UID in form of YYYYMMDDL. Setup test code to ensure binary compatibility with future versions.
 * Clean-up exception handling
  Some methods have currently signatures for exceptions they do not throw. Some code throws a simple RuntimeException instead of introducing a derived exception for the commons-id components. A lot of internally runtime exceptions are not mentioned in the javadoc.
 * Improve test path coverage and fix remaining style issues
 * Unify initialization of unit tests
  A lot of unit tests use a suite method, have a constructor to parametrise the name and have a main method. All of this is normally not necessary in modern IDEs. In Eclipse this is even worse, since you cannot click on the run tests to switch to the test's source. '''Done.'''
  
=== Documentation ===

 * Rewrite the introduction to commons-id, since it currently references the convenient classes, that will be dropped
 * Add existing identifier generators to overview table
 * Update UUID documentation after changes from the review
 * Add examples
 * Add FAQ

=== Javadoc ===

 * Drop duplicated javadoc
  If a method is overwritten in a derived class, it should either describe, what it does different or don't add any javadoc, so that the documentation is automatically copied by the javadoc tool. In case of repeated description for a single parameter, return value or thrown exception an {@inherit} element should be used.
  
=== Quality ===
  
=== Check Compatibility ===

 * Ensure JDK 1.3 compatibility

=== Build ===

 * Use Cobertura for coverage report
  '''Done.'''

== RC(s) ==

 * Once tasks above a completed, create release branch and roll a full RC
 * Repeat for n=2, 3, ... until all are happy (see below :-)

== Release Notes ==

== Release Vote(s) ==

If no objections are raised on problems reported with an RC after two days, a VOTE thread will be kicked off.  If problems are reported during the vote, these will be fixed and a new RC will be made available and a new VOTE initiated.  This process will iterate until we have had a successful VOTE thread extend for 72 hours.
  

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org