db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Planning for a 10.1 release
Date Sat, 21 May 2005 01:24:35 GMT
Daniel John Debrunner wrote:
> Though maybe the internal re-work could be separated into a follow on
> project, a common data source api could still use the current internal
> mechanism.

That's what I would do for an initial impl.

>>I think the only question is
>>whether they are a good idea or not: if they are a good idea then making
>>the changes now in this release is very desirable to avoid future
>>changes in the network client.   Surely it should be possible to
>>evaluate reasonably quickly whether the changes result in a simpler and
>>improved user experience.  As you may have guessed, I think they do :-)
> Not sure how we would evaulate quickly, I'm not convinced the scheme is
> easier and it may be more confusing to users.
> The other issue is do we hold up releasing 10.1 and the derby client to
> resolve this? Especially as we don't have any actual code or patch
> implementing it. How long would we wait and how does that tie into
> release early, release often?

Well, there is a strawman in the branch and we've not been discussing it 

> And that brings me to one solution, release soon without this change (as
> it doesn't exist), release once it does exist, and then let the users
> tell us which approach is better. Covers release early/often and the
> darwin aspect of open source.

Early implementation is one thing, but you want to get the public 
interfaces right, or at least easily extensible, from the start so you 
don't end up regretting something forever.

This is new functionality that was dropped into the project and 
questions were raised fairly quickly. Rushing out a first release (and 
hence committing to an API) without clear answers does no-one any good, 
neither users nor developers.


View raw message