db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Jefferson <a...@jpox.org>
Subject Re: [DISCUSS] JDO 2.1 maintenance release
Date Sat, 14 Oct 2006 16:33:34 GMT
Hi Craig,

To ChangeLog I would like to see the addition of support for Calendar.

> One rather large decision is whether to require JDK 1.5 for the
> release. I think there are three options, since part of the change
> requires JDK 1.5: annotations, Enum, and signature changes for generics.
> 1. Require JDK 1.5 for the 2.1 maintenance release.

I personally like the fact that JDO is JDK agnostic technology (and JPA 

> 2. Split the current maintenance release into two maintenance
> releases. Do the first maintenance release with no JDK 1.5 changes,
> and follow up in six months with another release that includes the
> 1.5 content.

So you have 2.1 (JDK 1.3+) and 2.2 (JDK 1.5+). And this effectively says that 
from 2.2 you must have JDK 1.5+ to use JDO ? So this is like option 3 except 
that you use SVN to handle the different API/TCK trees in separate branches 
rather than having them both present in the same branch (which option 3 
implies) ?  The end result is the same ... we have a JDK1.3+ jar and TCK, and 
we have a JDK1.5 jar and TCK

Therefore the JDO 2.1 branch can still be developed further in maintenance 
revisions as 2.1.1, 2.1.2 etc just like any software project so those who use 
JDK 1.3/1.4 can still use a developing technology whilst retaining their JDK, 
and those who use JDK 1.5+ can use the JDO2.2 branch.

Future development beyond 2.2 will be for JDK 1.5+ only (which by the time 
that happens there will be more than the current 20-30% of developers using 
it). Implementations could easily put out a JDO2.1 version and a JDO2.2 
version and claim compliance with either standard.

The only other issue to decide would be whether to use namings of JDO 2.1 and 
JDO 2.2 for these 2 branches, or whether to use 2.1 and 3.0, 
.... or maybe JDO 5 perhaps? muahahahaha

> 3. Split the maintenance release into two parts, one of which only
> requires JDK 1.3, and the other part which requires 1.5. Ship two
> sets of jar files for at least the api20 jar and tck20 jar, with
> different dependencies.

I'd guess most work would be to use the same TCK core in 2 different TCK maven 

Using option 2 seems like a better compromise to me.

> Please let me know which of these options you are willing to help with.

I'm "willing to help" on 2 or 3, since writing an RI qualifies as help IMHO. 
Also on the splitting of annotations between JDO and ORM.


View raw message