pushing back release date for jdbc4-capable Derby

[Rick Hillegas <Ri...@Sun.COM>]

A while ago, I volunteered to manage a Derby release which will include 
a new feature that is important to me: an implementation of JDBC4. Based 
on the JDBC4 schedule then, I had hoped to post that release in June. 
However, because the JDBC4 schedule moved back, I must post my release 
later, most likely in October. Here is the reason:

Under the terms of the JCP specification license, a product may not 
release for general availability if it implements JCP specification APIs 
that are not generally available. Two JCP specifications, JSRs 221 and 
270, affect Derby. JSR 221 governs JDBC4 and JSR 270 governs Java SE 6. 
JDBC4, as part of Java SE 6, is scheduled to go GA this autumn. See 
http://www.jcp.org/en/jsr/detail?id=221&showPrint and 
http://www.jcp.org/en/jsr/detail?id=270&showPrint. So a JDBC4-capable 
Derby GA cannot post till the fall.

I will continue to track the evolving JDBC4 spec and still expect to 
manage a release which implements that feature. However, you must 
understand that I do not have time to manage a June release as well.

I am sorry to bear this disappointing news.

Regards,
-Rick

Re: pushing back release date for jdbc4-capable Derby

["David W. Van Couvering" <Da...@Sun.COM>]

I think you are quite right that this is most likely too long to wait 
for the next release.  I think what Rick is saying is his personal itch 
is JDBC4, that's the release he wants to manage, and he's not up for 
managing two releases in a row.

I am hoping (and I am sorry to say I am not the one to do this with a 
new baby) that someone can volunteer to manage an earlier release so we 
can get some of this great new functionality (other than JDBC4) out to 
our users.

Helpful hint to anyone thinking of doing this: it is pretty darn easy to 
build a binary of Derby that does not include JDBC4 - just don't compile 
it with the JDK 1.6 compiler...  So hopefully we do not have to yank out 
all the JDBC4 work to do a release prior to the GA of the JDBC4 
specification.

David

Kathey Marsden wrote:
> Rick Hillegas wrote:
> 
> 
>>AHowever, because the JDBC4 schedule moved back, I must post my
>>release later, most likely in October.
> 
> 
> My big issue with this is that we seem to be totally deviating from a
> major tenant of  of open source development.
>     
> /Release early. Release often. And listen to your customers.
> /
> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html
> 
> How will we in the Derby development community reign in quality and
> compatibility issues especially with client and get the needed user
> feedback with such a  long release cycle?
> 
> Kathey
> 
> 

Re: pushing back release date for jdbc4-capable Derby

[Kathey Marsden <km...@sbcglobal.net>]

Rick Hillegas wrote:

> AHowever, because the JDBC4 schedule moved back, I must post my
> release later, most likely in October.

My big issue with this is that we seem to be totally deviating from a
major tenant of  of open source development.
    
/Release early. Release often. And listen to your customers.
/
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html

How will we in the Derby development community reign in quality and
compatibility issues especially with client and get the needed user
feedback with such a  long release cycle?

Kathey

Re: pushing back release date for jdbc4-capable Derby

[Andrew McIntyre <mc...@gmail.com>]

On 3/28/06, Rick Hillegas <Ri...@sun.com> wrote:
> A while ago, I volunteered to manage a Derby release which will include
> a new feature that is important to me: an implementation of JDBC4. Based
> on the JDBC4 schedule then, I had hoped to post that release in June.
> However, because the JDBC4 schedule moved back, I must post my release
> later, most likely in October. Here is the reason:
>
> Under the terms of the JCP specification license, a product may not
> release for general availability if it implements JCP specification APIs
> that are not generally available. Two JCP specifications, JSRs 221 and
> 270, affect Derby. JSR 221 governs JDBC4 and JSR 270 governs Java SE 6.
> JDBC4, as part of Java SE 6, is scheduled to go GA this autumn. See
> http://www.jcp.org/en/jsr/detail?id=221&showPrint and
> http://www.jcp.org/en/jsr/detail?id=270&showPrint. So a JDBC4-capable
> Derby GA cannot post till the fall.

Disregarding any potential legalities, would we, as a community really
want to release something that isn't known to be compliant with the
final version of the spec? That would seem to run counter to the
charter of the Derby project, specifically the Standards Based part:

http://db.apache.org/derby/derby_charter.html#Standards+based

I assume you mentioned legalities because the ASF is a JCP member:

http://jcp.org/en/participation/members/A

However, in this case I don't think we need to consider any legal issues.

> I will continue to track the evolving JDBC4 spec and still expect to
> manage a release which implements that feature. However, you must
> understand that I do not have time to manage a June release as well.
>
> I am sorry to bear this disappointing news.

I don't think there's a need to be disappointed. :-) These things
happen. Personally, I think it makes sense from several perspectives
to have a release around JDBC 4 that implements the final version of
the spec, not an early draft. Does anyone disagree?

That said, October is a long way away. That would be almost a year
between the 10.1.2 release and 10.2. So, I think it would be a good
idea to have another 10.1 maintenance release in the meantime. There
have been numerous XA fixes which have gone into the 10.1 branch
recently, and perhaps we can have another "bug drive" like Kathey held
for 10.1.2 to drum up some interest in fixing some of the numerous
open code bugs and porting some of the smaller fixes from 10.2 to 10.1
(like the recent fix for retrieving Float values, e.g.).

And since I suggested it, yes, I'll volunteer to head up the 10.1.3 release. :-)

andrew

Re: pushing back release date for jdbc4-capable Derby

[Daniel John Debrunner <dj...@apache.org>]

Rick Hillegas wrote:

> Note that our current nightly snapshots don't contain the jdbc40
> classes. We could:
> 
> 1) Change the nightly build to always generate the jdbc40 support or
> 2) Hand-generate a snapshot early in May

+1 to both.

The benefit of a snapshot is that we can put some words around it,
rather than just a nightly build.

By words, I mean a small writeup of what's new for people to try out and
test.

Dan.

Re: pushing back release date for jdbc4-capable Derby

[Ramandeep Kaur <ra...@gmail.com>]

+1

for both

Ramandeep Kaur
ramandhindsa@gmail.com

Re: pushing back release date for jdbc4-capable Derby

[Ole Solberg <Ol...@Sun.COM>]

Dag H. Wanvik wrote:
> Manjula G Kutty <ma...@gmail.com> writes:
> 
> 
>>Rajesh Kartha wrote:
>>
>>
>>>Rick Hillegas wrote:
>>>
>>>
>>>>Note that our current nightly snapshots don't contain the jdbc40

Daily builds with JDBC40 support are now available at
http://www.multinet.no/~solberg/public/Apache/DerbyJDK16/builds/

>>>>classes. We could:
>>>>
>>>>1) Change the nightly build to always generate the jdbc40 support or
>>>>2) Hand-generate a snapshot early in May
>>>>
>>>>(1) seems more useful to me.
>>>>
>>>>Regards,
>>>>-Rick
>>>>
>>>
>>>+1.
>>>A snapshot of 10.2 jars  is desirable as well, for early testing of
>>>the enhancements added.
>>>
>>>-Rajesh
>>>
>>
>>+1
>>
>>for both
> 
> 
> +1 for both.
> 
> Dag


-- 
Ole Solberg, Database Technology Group,
Sun Microsystems, Trondheim, Norway

Re: pushing back release date for jdbc4-capable Derby

["Dag H. Wanvik" <Da...@Sun.COM>]

Manjula G Kutty <ma...@gmail.com> writes:

> Rajesh Kartha wrote:
>
>> Rick Hillegas wrote:
>>
>>> Note that our current nightly snapshots don't contain the jdbc40
>>> classes. We could:
>>>
>>> 1) Change the nightly build to always generate the jdbc40 support or
>>> 2) Hand-generate a snapshot early in May
>>>
>>> (1) seems more useful to me.
>>>
>>> Regards,
>>> -Rick
>>>
>> +1.
>> A snapshot of 10.2 jars  is desirable as well, for early testing of
>> the enhancements added.
>>
>> -Rajesh
>>
> +1
>
> for both

+1 for both.

Dag

Re: pushing back release date for jdbc4-capable Derby

[Manjula G Kutty <ma...@gmail.com>]

Rajesh Kartha wrote:

> Rick Hillegas wrote:
>
>> Note that our current nightly snapshots don't contain the jdbc40 
>> classes. We could:
>>
>> 1) Change the nightly build to always generate the jdbc40 support or
>> 2) Hand-generate a snapshot early in May
>>
>> (1) seems more useful to me.
>>
>> Regards,
>> -Rick
>>
> +1.
> A snapshot of 10.2 jars  is desirable as well, for early testing of 
> the enhancements added.
>
> -Rajesh
>
+1

for both

-Manjula

Re: pushing back release date for jdbc4-capable Derby

[Rajesh Kartha <ka...@gmail.com>]

Rick Hillegas wrote:

> Note that our current nightly snapshots don't contain the jdbc40 
> classes. We could:
>
> 1) Change the nightly build to always generate the jdbc40 support or
> 2) Hand-generate a snapshot early in May
>
> (1) seems more useful to me.
>
> Regards,
> -Rick
>
+1.
A snapshot of 10.2 jars  is desirable as well, for early testing of the 
enhancements added.

-Rajesh

Re: pushing back release date for jdbc4-capable Derby

[Rick Hillegas <Ri...@Sun.COM>]

Note that our current nightly snapshots don't contain the jdbc40 
classes. We could:

1) Change the nightly build to always generate the jdbc40 support or
2) Hand-generate a snapshot early in May

(1) seems more useful to me.

Regards,
-Rick

Daniel John Debrunner wrote:

>Andrew McIntyre wrote:
>
>  
>
>>On 3/28/06, David W. Van Couvering <Da...@sun.com> wrote:
>>
>>    
>>
>>>I think this sounds like a good idea.  That said, I'm sure I'm missing
>>>something, but can someone explain the difference between a snapshot of
>>>the trunk in May and a snapshot of Derby 10.2 in May?
>>>      
>>>
>>Since trunk = 10.2, they would be one and the same thing. I think what
>>Dan is suggesting is posting a snapshot of 10.2 alpha which includes
>>the JDBC 4.0 driver once some significant portion of it has been
>>implemented, so that the community-at-large can begin testing.
>>    
>>
>
>+1 snapshot of the trunk which currently is labelled as 10.2.
>
>Dan.
>
>  
>

Re: pushing back release date for jdbc4-capable Derby

[Daniel John Debrunner <dj...@apache.org>]

Andrew McIntyre wrote:

> On 3/28/06, David W. Van Couvering <Da...@sun.com> wrote:
> 
>>I think this sounds like a good idea.  That said, I'm sure I'm missing
>>something, but can someone explain the difference between a snapshot of
>>the trunk in May and a snapshot of Derby 10.2 in May?
> 
> 
> Since trunk = 10.2, they would be one and the same thing. I think what
> Dan is suggesting is posting a snapshot of 10.2 alpha which includes
> the JDBC 4.0 driver once some significant portion of it has been
> implemented, so that the community-at-large can begin testing.

+1 snapshot of the trunk which currently is labelled as 10.2.

Dan.

Re: pushing back release date for jdbc4-capable Derby

[Andrew McIntyre <mc...@gmail.com>]

On 3/28/06, David W. Van Couvering <Da...@sun.com> wrote:
> I think this sounds like a good idea.  That said, I'm sure I'm missing
> something, but can someone explain the difference between a snapshot of
> the trunk in May and a snapshot of Derby 10.2 in May?

Since trunk = 10.2, they would be one and the same thing. I think what
Dan is suggesting is posting a snapshot of 10.2 alpha which includes
the JDBC 4.0 driver once some significant portion of it has been
implemented, so that the community-at-large can begin testing.

andrew

Re: pushing back release date for jdbc4-capable Derby

["David W. Van Couvering" <Da...@Sun.COM>]

I think this sounds like a good idea.  That said, I'm sure I'm missing 
something, but can someone explain the difference between a snapshot of 
the trunk in May and a snapshot of Derby 10.2 in May?

Thanks,

David

Daniel John Debrunner wrote:
> Rick Hillegas wrote:
> 
> 
>>A while ago, I volunteered to manage a Derby release which will include
>>a new feature that is important to me: an implementation of JDBC4. Based
>>on the JDBC4 schedule then, I had hoped to post that release in June.
>>However, because the JDBC4 schedule moved back, I must post my release
>>later, most likely in October. Here is the reason:
> 
> 
> It would be great to get a Derby 10.2 alpha snapshot up on the download
> page around the start of May. This would coincide with the date that
> everyone was working to, so it seems that some significant
> functionality, including JDBC 4.0, would be available for people to try.
> 
> Dan.
> 

Re: pushing back release date for jdbc4-capable Derby

[Daniel John Debrunner <dj...@apache.org>]

Rick Hillegas wrote:

> A while ago, I volunteered to manage a Derby release which will include
> a new feature that is important to me: an implementation of JDBC4. Based
> on the JDBC4 schedule then, I had hoped to post that release in June.
> However, because the JDBC4 schedule moved back, I must post my release
> later, most likely in October. Here is the reason:

It would be great to get a Derby 10.2 alpha snapshot up on the download
page around the start of May. This would coincide with the date that
everyone was working to, so it seems that some significant
functionality, including JDBC 4.0, would be available for people to try.

Dan.