-----BEGIN PGP SIGNED MESSAGE----- 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 patch? > > > I dont think there is a need to branch for simple additions of new features > 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 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=1903749 Dan. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBo8UZIv0S4qsbfuQRAuPzAJ9bgrFNWwfP3ifyyiYlPgBlW3MawQCfaVOq wXpXyG3bL7Rbb4I5nxUfTAA= =qlPq -----END PGP SIGNATURE-----
