Here's the email I thought I had sent to the whole list...
David
--- Begin Message ---
I agree that "no law" would be bad, but I was thinking that the standard
patch review process we apply (and the general rule of being able to
review and back out any committed change) was sufficient for class and
method level changes. I could say that any addition to shared
components should in general involve a patch review before a commit...
David
TomohitoNakayama wrote:
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
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message ----- From: "Apache Wiki" <[EMAIL PROTECTED]>
To: <[email protected]>
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.
+
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
--- End Message ---
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
