db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <e...@jpox.org>
Subject RE: Logistics for JDO maintenance release
Date Sun, 05 Nov 2006 20:44:03 GMT

Isn’t it possible to have a jar with dual compatibility? Previous
classes are 1.3 binary compatible and the annotation classes are 1.5?
Erik Bengtson

-----Original Message-----
From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM] 
Sent: Saturday, November 04, 2006 10:37 PM
To: Apache JDO project
Subject: Logistics for JDO maintenance release

[apologies for the html formatting, needed for the tables below]

Based on the feedback I received for the maintenance release, I'd like
to propose that we put both the jdk1.5 changes as well as the jdk1.3
changes into the specification. When running with jdk1.5 features, the
jdo api jar needs to be different in order to accommodate the new
signatures of the apis that are now generic. Similarly, in order to test
the new jdk1.5 features, the tck jar needs to be different to use the
new signatures. I think the most straightforward way to do this is to
create different jar files that are self-contained. This implies that we
have different artifact names and build them with different svn

Our current workspaces are trunk and branches/2.0.1. I'd like to propose
we create new projects corresponding to api20 and tck20 that contain the
jdk1.5 changes for the maintenance release. When we branch the
workspaces for the release, we can change the version number from
SNAPSHOT to 2.1.

For naming, here's what we currently have:
directory   groupId        artifactId version
---------   -------        ---------- -------
trunk/api20 javax.jdo      jdo2-api   SNAPSHOT
trunk/tck20 org.apache.jdo jdo2-tck   SNAPSHOT

I think we need to change the project names and the artifact ids for the
new release. [I think it will be confusing to have the maintenance
release with two different release numbers, one reflecting 1.3 and the
other 1.5. I'd like to propose changing the artifact names instead.]

We can work on the 1.3 and 1.5 workspaces at the same time. We need to
migrate any of the 1.3 changes into the 1.5 project also. Changes in the
1.5 don't need to be ported back to the 1.3. Bug fixes of course can be
migrated from the 2.0.1 branch into both the 1.3 and 1.5 projects in
trunk. After release, we can create a new 2.1.1 branch that we use for
maintenance of the 2.1 code line.

Here's my proposal for naming; I just stuck a "5" in the names in an
arbitrary place:
directory           groupId        artifactId version
---------           -------        ---------- -------
trunk/api205        javax.jdo      jdo2-api5  SNAPSHOT
trunk/tck205        org.apache.jdo jdo2-tck5  SNAPSHOT
branches/2.1/api205 javax.jdo      jdo2-api5  2.1
branches/2.1/tck205 org.apache.jdo jdo2-tck5  2.1
branches/2.1/api20  javax.jdo      jdo2-api   2.1
branches/2.1/tck20  org.apache.jdo jdo2-tck   2.1

I'm open to other project and artifactId names. Here are a few that
might work. I'd welcome other suggestions. Keep in mind that maven
concatenates the artifactId, "-", and version number to produce the file
name for the artifact jars, signatures, and checksums.

api205 jdo2-api5 ==> jdo2-api5-2.1.jar
api25 jdo25-api ==> jdo25-api-2.1.jar
api2-5 jdo2-5-api  ==> jdo2-5-api-2.1.jar
api2-1.5 jdo2-1.5-api  ==> jdo2-1.5-api-2.1.jar


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message