db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Planning for a 10.1 release
Date Wed, 25 May 2005 20:38:21 GMT
I think one of the advantages of an open source product is the ability
to expose new functionality, with the understanding that it may change
in the future due to user feedback and changing standards.  My hope 
would be that we could use this kind of change to push a new standard if 
appropriate, providing a working real world working example.  As long as
it is properly documented I would rather see it included in the 
distribution as a number of users of the product will never apply a
patch and build their own version.

I also would like to see more release early, release often.  Along with
this I like incremental development where a large project is broken
down into smaller pieces which can be checked into the trunk along the
way.  At each step existing functionality must not be broken, but it
may be the case that larger project does not work completely until
it is all checked in.  A given release may only contain the groundwork
to get a larger project working, but that should not hold up the
release.  I think it is better for everyone to share the working code
early.

My criteria for allowing a checkin to the trunk is if the added 
functionality does not break existing functionality, and the added code
is progressing toward a change derby would eventually benefit from.  To 
that end adding an XML datatype seems like a excellent candidate.  With 
derby there aren't a lot of areas like
adding a datatype where other paths are not affected, but this is
one.  We should appropriately document the "expermental" nature of this
particular feature warning that it's interfaces are not set yet.  I am
ok with just documenting it, we could also implement properties that 
must be set to use the feature.


Andrew McIntyre wrote:
> On May 24, 2005, at 6:29 PM, Army wrote:
> 
>     I should clarify. The reason I was thinking that this should not be
>     documented as "official" yet is because the work I've done is based
>     on _working__drafts_ of the SQL/XML syntax--which means we run the
>     risk of the syntax changing in the near future.
> 
> 
> I see. Not so much incomplete or experimental as "preliminary". I think 
> that's even the word used in your original post. Sorry for the confusion.
> 
> On May 24, 2005, at 9:04 PM, Daniel John Debrunner wrote:
> 
>     I think it's more than just quality and in fact Army never says
>     anything
>     about "production quality".
> 
> 
> Indeed he didn't, but I was using Army's patch as an example to respond 
> generally to the suggestion that something that is "experimental" be 
> added to a release (thus, before it is "ready".)
> 
> I think you said it best with:
> 
>     The release manager doesn't want to be endlessly delaying a release
>     waiting for one
>     or more contributors to submit or finish patches.
> 
> 
> +1
> 
> Also, I plan on updating STATUS shortly with the collected feedback, 
> it's more than a little out of date and could use some new info.
> 
> andrew
> 


Mime
View raw message