| If we do need checkins to the trunk after the branch is created (the branch is an svn activity that sends a message to jdo-commits alias) then they will need to be done to both the trunk and branch. Of course, there are some branch-only things (changing from SNAPSHOT to 2.0 in project.xml). But I don't know of any issues that will require branch/trunk checkins.
Craig On Mar 28, 2006, at 7:40 PM, Michelle Caisse wrote: Craig,
Does this mean there will be no more check-ins? Or will we just check in to both trunk and release branch for the few remaining issues?
-- Michelle
Craig L Russell wrote:
Javadogs,
I'm planning on cutting the release branch for JDO 2.0 tomorrow. There are three open issues that I'm aware of:
1. The test with persistent interfaces doesn't work yet; I believe that this is a JPOX bug that will be fixed without a new release of the API or TCK.
2. The TCK only supports datastore identity with strategy="identity". This is an issue for vendors who cannot use this strategy for databases that do not support the SQL GENERATED ... AS IDENTITY construct for schema. I believe that we can resolve this TCK issue after release of 2.0.
3. Synchronization with JPOX final 1.1.0 release. The JPOX team need to have an api20 release post-jdo-2.0-rc1 that includes a signature change for a FetchPlan method. But I think that it's going to have to either depend on a SNAPSHOT api20 or a renamed api20 release for testing. Similarly, for testing the jdo 2.0 bits, we will need to test with SNAPSHOT JPOX bits renamed to jpox-1.1.0.
Please let me know if you feel that it is not appropriate to start the release process with the api20 and tck20 bits currently checked into SVN.
Thanks,
Craig Craig Russell P.S. A good JDO? O, Gasp!
|
smime.p7s
Description: S/MIME cryptographic signature
