db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "TomohitoNakayama" <tomon...@basil.ocn.ne.jp>
Subject Re: [Db-derby Wiki] Update of "SharedComponentVersioningGuidelines" by DavidVanCouvering
Date Sat, 15 Oct 2005 14:26:08 GMT
Hello.

I think rule of vote for new shared package is reasonable.

However, I feel uncomfortable about rule of new class and new method .
It looks as though there exists no law , once shared package was created.

I think vote for new class and new method in shared package is not required , however, is
recommended .
I wonder lazy consensus may be good criterion ...
http://www.apache.org/foundation/voting.html#LazyConsensus

Best regards.

/*

         Tomohito Nakayama
         tomonaka@basil.ocn.ne.jp
         tomohito@rose.zero.ad.jp
         tmnk@apache.org

         Naka
         http://www5.ocn.ne.jp/~tomohito/TopPage.html

*/
----- Original Message ----- 
From: "Apache Wiki" <wikidiffs@apache.org>
To: <derby-commits@db.apache.org>
Sent: Saturday, October 15, 2005 3:44 AM
Subject: [Db-derby Wiki] Update of "SharedComponentVersioningGuidelines" by DavidVanCouvering


> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.
>
> The following page has been changed by DavidVanCouvering:
> http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines
>
> ------------------------------------------------------------------------------
>  == Deprecation Guidelines ==
>  A method or an interface may be deprecated.  This is done using the @deprecated tag
in the method or interface Javadoc.  A method 
> or interface must be available for 2 major releases after it is deprecated.  For example,
if it is deprecated in version 8.2, it 
> can be removed in version 10.0 or greater.  An exception to this rule may occur if it
becomes clear that there is still heavy use 
> of this interface.
>
> - == Distribution of Shared Components ==
> + == Location and Distribution of Shared Components ==
>
> - To help make explicit the various shared components within Derby and what is contained
in them, our internal build will create a 
> seprate JAR file for each shared component.
> + All shared components should comprise of one or more packages under the package {{{org.apache.derby.common}}}
(stored in the 
> source tree under {{{java/common/org/apache/derby/common}}}).
>
> - However, to keep a very simple user experience, when we create a release, the classes
in the shared component JAR files will be 
> merged into derby.jar and derby-client.jar.
> + Although it would be conceptually nice to have a separate JAR file for each shared
component, it is a priority for us to keep a 
> very simple user experience.  For this reason, the classes of a shared components will
be merged into the appropriate subset of 
> the existing jar files.
>
> + == Documenting Shared Components ==
>
> - == Introducing New Shared Components ==
> + We will provide a top-level {{{README}}} file under {{{java/org/apache/derby/common}}}
that describes the shared components 
> guidelines (once they are approved) and lists the available components.  For each shared
component we will provide:
>
> - Any new shared component, or a significant addition to an existing shared component,
that a developer wishes to introduce should 
> be put up for a vote.  This is to help ensure that what we are sharing makes sense and
does not accidentally paint us into some 
> kind of architectural corner.
> +    * Name of component
> +    * Description of component (its role or intent)
> +    * Packages contained within the component
> +    * The name of the Info class that provides the hasFeature() method
>
> + == Introducing New Shared Components and Shared Packages ==
> +
> + When a developer wishes to introduce a new shared component or a new package within
an existing shared component, this should be 
> put up for a vote.  This is to help ensure that what we are sharing makes sense and does
not accidentally paint us into some kind 
> of architectural corner.  Adding new classes or methods to an existing shared package
does not need to be put up for a vote.
> +
>
> 


Mime
View raw message