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: [VOTE][PATCH] delete from the resultset using JDBC 2.0 Updatable Resultset APIs
Date Tue, 23 Nov 2004 23:17:46 GMT
Hash: SHA1

Jan Hlavatý wrote:

> Daniel John Debrunner wrote:
>>This is a new feature, and is in fact a "partial" feature, just delete
>>support for JDBC 2 updatable result sets. This then leads to the
>>question that is it time to branch the codeline before applying this
> I dont think there is a need to branch for simple additions of new
> which do not change the current functionality in any way, only add to it.
> We can keep these changes from being used by not documenting them
until they
> are ready ;)

Part of the benefit of open source is that users can test out features
before they become part of a release, and hence bugs can be found
earlier. This should include the code and the documentation. So I don't
believe we should hide features by intentional lack of documentation.

The issue with not branching is that there is the risk that the addition
of new features introduces bugs into existing functionality. And the
risk increases with the number of features. In some cases it may be
because the best choice is to re-write existing functionality.

A stable branch for a release is just that, stable. Limited work is
allowed in it, typically just bug fixes. This gives users the confidence
to pick up releases from that branch, knowing the risk of a new database
engine breaking their application is very low. Some paranoid users are
very keen to know the complete list of changes made to a new version of
a piece of software before they are willing to accept it. If that list
includes too many changes there is the chance they will not accept it.
This might then lead to users having to build their own versions of
Derby, with their base and a handful of bug fixes pulled from commits in
the trunk. I don't think this would endear Derby to most users.

I think it was generally agreed that branches for a release was a good
idea, see

Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


View raw message