[ Post a follow-up to this message ]

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
>
> 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!
>
>

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

I have JDO-293, which is dependent on JDO-273 finishing touches.
There's also JDO-64 that is still open. And JDO-349.

-- Michelle

Craig L Russell wrote:

> 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 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!
>
>

[ Post a follow-up to this message ]

Michelle, Craig,

Michelle Caisse wrote:
> I have JDO-293, which is dependent on JDO-273 finishing touches.
> There's also JDO-64 that is still open. And JDO-349.
>
> -- Michelle

I currently cannot lookup JDO-293 (apache server seems to be down),
so, I'm not sure about your dependency, but I don't anticipate code
changes for JDO-273 (and will set it to resolved after my AI below).

Michelle Caisse wrote:
>
> It would be great if you could add anything that you know is missing, as
> a range of assertion numbers or a set of ranges.  Then I could check it
> against the spreadsheet and make sure we have all tested assertions
> marked "yes".

What I'd recommend is that
- the StateTransition tests only refer to A5.9.1..190, which denotes
the global state transition table in the spec and that
- we mark all other state-transition related assertions in the
lifecycle tab of the spreadsheets as duplicates of A5.9.1..190, as
is done for a few (but not all).

I'm currently going over the lifecycle spreadsheet, checking the
transition-related assertions for coverage by A5.9.1..190 and the
newly implemented cases, and preparing a few comments (which I'll
send to you soon).

Now, for the unlikely event that I find any transition assertions not
covered by the global state transition matrix (A5.9.1..190), Craig
would propably rather want to complete the matrix in the spec (errata)
instead of me adding additional assertions to StateTransition*.java.
But even if I did update StateTransition*.java, it only would be for
a message string and a comment.

Martin

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

Martin Zaun wrote:

>
> Michelle, Craig,
>
> Michelle Caisse wrote:
> 
>
>
> I currently cannot lookup JDO-293 (apache server seems to be down),
> so, I'm not sure about your dependency, but I don't anticipate code
> changes for JDO-273 (and will set it to resolved after my AI below).

This is just about listing all the assertions tested by the lifecycle
test.  Then I can finalize the spreadsheet.

-- Michelle

[ Post a follow-up to this message ]

Craig L Russell wrote:
 
>
>
> This sounds like a reasonable approach. I don't know if there is
> value in adding duplicate assertions to the test cases. I think these
> can be handled by referring the duplicates to the state transition
> section of the assertion spreadsheet.

Would it be best if I check in the spreadsheet with my current changes
so you can then mark the appropriate assertions as duplicates?  I may
need to make some further changes after you are done to update the count
of tested assertions.

-- Michelle

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

Done.  -- Michelle

Craig L Russell wrote:

> Yes, please check in the worksheet as you have it.
>
> Craig
>
> On Mar 29, 2006, at 11:43 AM, Michelle Caisse wrote:
> 
>
>
> 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!
>

[ Post a follow-up to this message ]