Hi Mike,
Some responses follow. Regards-Rick
Mike Matrigali wrote:
Rick Hillegas wrote:
Thanks, Kathy. I think I'm getting the message that the following
would be an acceptable and more traditional schedule:
August 10 : Last feature work commits
August 11 : First release candidate
Rick Hillegas wrote:
Last week, Sun Microsystems announced that it will bundle Derby with
the next major release of the reference jdk, Java SE 6, also known as
Mustang or jdk1.6. If you download the latest Mustang build, you will
see that it contains our Derby 10.2.0.3 snapshot in the db
Thanks, Rajesh. In your scheme, when should feature work on 10.2 wrap
up? I had budgeted 2 weeks between the end of feature work and the first
release candidate. Is that overkill? Should we propose that feature work
wraps up by, say, July 27?
Rajesh Kartha wrote:
Rick Hillegas wrote:
Last
Rick Hillegas wrote:
Thanks, Rajesh. In your scheme, when should feature work on 10.2 wrap
up? I had budgeted 2 weeks between the end of feature work and the
first release candidate. Is that overkill? Should we propose that
feature work wraps up by, say, July 27?
Do we need to have a
Thanks, Kathy. I think I'm getting the message that the following would
be an acceptable and more traditional schedule:
August 10 : Last feature work commits
August 11 : First release candidate generated
August 24 : Second release candidate generated
September 7: Third and hopefully last
Rick Hillegas wrote:
Thanks, Kathy. I think I'm getting the message that the following
would be an acceptable and more traditional schedule:
August 10 : Last feature work commits
August 11 : First release candidate generated
August 24 : Second release candidate generated
September 7: Third
Kathy Saunders wrote:
Rick Hillegas wrote:
Thanks, Kathy. I think I'm getting the message that the following
would be an acceptable and more traditional schedule:
August 10 : Last feature work commits
August 11 : First release candidate generated
August 24 : Second release candidate
Rick Hillegas wrote:
Thanks, Kathy. I think I'm getting the message that the following would
be an acceptable and more traditional schedule:
August 10 : Last feature work commits
August 11 : First release candidate generated
August 24 : Second release candidate generated
September 7: Third
Mike Matrigali wrote:
Rick Hillegas wrote:
Thanks, Kathy. I think I'm getting the message that the following
would be an acceptable and more traditional schedule:
August 10 : Last feature work commits
August 11 : First release candidate generated
August 24 : Second release candidate
Jean T. Anderson wrote:
I believe some of the features were already originally planning on
an august 15 or later date, and have adjusted to an august 10 date.
Some definitely won't make it with an earlier code freeze.
There's no code freeze per se on ASF projects.
sorry, I never meant
Last week, Sun Microsystems announced that it will bundle Derby with the
next major release of the reference jdk, Java SE 6, also known as
Mustang or jdk1.6. If you download the latest Mustang build, you will
see that it contains our Derby 10.2.0.3 snapshot in the db directory
parallel to lib
Rick Hillegas wrote:
The JCP requires that our JDBC4-exposing release can not be generally
available until the JDBC4 specification is finalized.
Is this something that the Derby community is bound to?
Here are proposed dates for 10.2 milestones:
August 10 - Feature work committed. 10.2
Hi Kathey,
Thanks for raising these issues. Here are some clarifications.
Regards,
-Rick
Kathey Marsden wrote:
Rick Hillegas wrote:
The JCP requires that our JDBC4-exposing release can not be generally
available until the JDBC4 specification is finalized.
Is this something that the
Rick Hillegas wrote:
Last week, Sun Microsystems announced that it will bundle Derby with the
next major release of the reference jdk, Java SE 6, also known as
Mustang or jdk1.6.
To be precise, Sun Microsystems announced that it will bundle Java DB
with Mustang.
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
What happens between September 15 and End of October on the 10.2 branch?
If we fix critical bugs during that time in the 10.2 branch can't they
go into the release end of October?
They should be able to. Since we won't
Rick Hillegas wrote:
Hi Dan,
Thanks for your comments. Some further remarks follow.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
What happens between September 15 and End of October on the
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Hi Dan,
Thanks for your comments. Some further remarks follow.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
What
Rick Hillegas wrote:
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Hi Dan,
Thanks for your comments. Some further remarks follow.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
Rick Hillegas wrote:
Daniel John Debrunner wrote:
The mid-Sep Derby release candidate will be marked alpha or beta (JCP
rules) so the databases won't upgrade anyway.
I apologize for creating confusion here. We'd like Mustang to ship with
a fully functional Derby, which creates
Ok, this is very tricky. First, I'd like to make sure we're on the same
page here about Java DB going into the JDK. I think in general the
community thinks it's a good thing for Derby for Java DB to be in the
JDK. It gives us great exposure and distribution. I also think the
community
David Van Couvering wrote:
...
In order for this to work, we need Java DB to be based on an official,
GA-ready release of Derby to be what Sun redistributes in Mustang.
Otherwise databases created in Mustang will be locked in to Java DB.
The problem is that it can't *actually* be GA until
Jean T. Anderson wrote:
David Van Couvering wrote:
...
In order for this to work, we need Java DB to be based on an official,
GA-ready release of Derby to be what Sun redistributes in Mustang.
Otherwise databases created in Mustang will be locked in to Java DB.
The problem is that it can't
Andrew McIntyre wrote:
Call in the lawyers:
From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board
has executed, being a JCP Member (they've even got quotes from Geir
prominently featured on their about JCP 2.6 page [2]):
5.B. License to Create Independent
Jean and Dan, you raise good points
(a) what happens if someone downloads this GA-ready but not GA release
of Derby. If for some reason we have to do a respin of the release (see
(b)), how will they later know that it's not actually an official
release of Apache?
(b) is there a
Andrew McIntyre wrote:
Anyway, what's the trigger for breaching the contract here? If it's
'creation' alone, then rolling that release candidate surely qualifies
as as creation. If it's 'creation and distribution,' well, is posting
the release candidate in a public forum and on a public website
Daniel John Debrunner wrote:
Andrew McIntyre wrote:
Call in the lawyers:
From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board
has executed, being a JCP Member (they've even got quotes from Geir
prominently featured on their
that was MUCH clearer than what rick wrote.. thanks
David Van Couvering wrote:
Ok, this is
very tricky. First, I'd like to make sure we're on the same page here
about Java DB going into the JDK. I think in general the community
thinks it's a good thing for Derby for Java DB to be in the JDK.
David Van Couvering wrote:
Andrew McIntyre wrote:
Or maybe ask Geir, since he's VP of Java Community Process for the
Apache Software Foundation, since similar instances may have come up
fairly recently. [3]
Even if we did ask Geir, he's not the last word on it. I'd rather hear
it from
Lance J. Andersen wrote:
You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final.
Are you *sure* you can't *have* a GA version, e.g the bits can't exist
somewhere, as long as they're not officially declared generally
available? If we can't even create the bits, then it
OK, good point, thanks.
David
Daniel John Debrunner wrote:
David Van Couvering wrote:
Andrew McIntyre wrote:
Or maybe ask Geir, since he's VP of Java Community Process for the
Apache Software Foundation, since similar instances may have come up
fairly recently. [3]
Even if we did ask
Hi, Lance. Sorry I had to challenge you publicly on the list, but
I'm really worried that if we're not very careful we are going to paint
ourselves into a corner and we are going to have to fork Derby in order
to do a Java DB release.
I think we need the JCP lawyers (and it sounds like the
That said, it's probably also good to hear from the JCP as well. It
would probably help the ASF gauge what their exposure is and what
approaches they feel comfortable with.
David
David Van Couvering wrote:
OK, good point, thanks.
David
Daniel John Debrunner wrote:
David Van Couvering
David Van Couvering wrote:
Lance J. Andersen wrote:
You cannot have a GA version of a JDBC 4 driver until JSR 221 goes
final.
Are you *sure* you can't *have* a GA version, e.g the bits can't exist
somewhere, as long as they're not officially declared generally
available? If we can't
Hi,Jean commented on David's post:... In order for this to work, we need Java DB to be based on an official,"GA-ready" release of Derby to be what Sun redistributes in Mustang.Otherwise databases created in Mustang will be "locked in" to Java DB.The problem is that it can't *actually* be GA until
34 matches
Mail list logo
