db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Planning for a 10.1 release
Date Wed, 25 May 2005 04:04:43 GMT
Andrew McIntyre wrote:
> On 5/24/05, David Van Couvering <David.Vancouvering@sun.com> wrote:
> 
>>I think the XML functionality will be of great interest to users, and
>>they would like to play around with it.
>>
>>If there was a way we could document this as "experimental work" and
>>were explicit about its level of maturity, this would be reasonable.
>>I'm not sure what "support" means for an open source project...
> 
> 
> Maybe it's just me, but I feel that, even for an open source project,
> having an official release implies a certain level of code quality. If
> Army doesn't think his code is going to be production-quality in the
> timeframe of the release we're currently discussing, I think it should
> be left out, even if it were to be undocumented.

I think it's more than just quality and in fact Army never says anything
about "production quality".

Looking at this for any feature, the issues (in order) for any suggested
functionality are:

 1) will a patch be ready in time for a release? Unless the
functionality is the driving force behind a release, then a release
should not be held up for a patch that doesn't exist yet. The release
manager doesn't want to be endlessly delaying a release waiting for one
or more contributors to submit or finish patches. Release early, release
*often* means that such a patch can soon be in another release.

 2) is the API to the functionality correct? Is this api (either Java
classes, Jean Bean properties, SQL syntax, etc.) something that Derby
should keep stable for some number of releases?
This is probably the hardest issue to address, given that while Derby is
open source and thus no guarantees are made, in order to be widely used
the api's can not be changed every release. Though it may not be that
any api has to be present forever, the user community can provide input
to any api question, including removing an api. In some cases, like XML,
it seems it would make sense to provide some warnings on the
functionality indicating that they may change due to in-flux standards,
but discussion about such future changes would need to include the user
community. I don't want Derby to be in a position where it becomes hard
to release functionality until we get it 100% perfect.

 3) Is the quality good enough? I would hope that code committed in the
trunk should be production quality, and this is enforced by
   * functional tests
   * code reviews
   * eyes on the code
and the quality is further enhanced by getting the functionality into
user's hands, allowing them to test it. (release *early*, release often).

> And there are a couple of different ways for users to get access to
> this new feature for testing: anyone interested in early access can
> apply Army's patch to their view and try out the code once it is
> available, or as soon as the release is done, we can put up a snapshot
> of the latest trunk version that includes the XML support for users to
> try out.

Getting the functionality into a release will see wider use of it and
thus lead to higher quality, due to the feedback.

Other things to remember that we can always make subsequent 10.1
releases with bug fixes that improve the quality and that anyone can
make a 10.2 release anytime after Andrew makes a 10.1 release.

Dan.


Mime
View raw message