FAQ
Olga posted cross-db test results for 3.0 branch a couple of days ago.
Doesn't look like we have any new regression issues. So I built the
RC2 artifacts that are posted here:

http://people.apache.org/~aadamchik/release/3.0RC2/

please check and cast your votes.

(BTW, we don't have any open issues against 3.0, so hopefully between
now and final release, the only changes that we'll have is
documentation).

Andrus

Search Discussions

  • Andrey Razumovsky at Jan 20, 2010 at 9:27 pm
    Accidently right after starting playing with new artifact CAY-1368
    apperared, which I find rather serious. Also some problems with EJBQL are
    reported by users. CAY-1368 is now fixed, other issues will probably do this
    week. Since this is expected to be latest milestone, may I ask that you
    redeploy artifacts after EJBQL issues are finished and we test it again?

    2010/1/17 Andrus Adamchik <andrus@objectstyle.org>
    Olga posted cross-db test results for 3.0 branch a couple of days ago.
    Doesn't look like we have any new regression issues. So I built the RC2
    artifacts that are posted here:

    http://people.apache.org/~aadamchik/release/3.0RC2/<http://people.apache.org/%7Eaadamchik/release/3.0RC2/>

    please check and cast your votes.

    (BTW, we don't have any open issues against 3.0, so hopefully between now
    and final release, the only changes that we'll have is documentation).

    Andrus

    --
    Andrey
  • Andrus Adamchik at Jan 20, 2010 at 10:24 pm

    On Jan 20, 2010, at 11:26 PM, Andrey Razumovsky wrote:
    CAY-1368 is now fixed, other issues will probably do this week.
    The fix seems to have some global consequences (unsurprisingly, as it
    changes some fundamental methods in DbEntity and ObjEntity). I haven't
    looked at the details, but we do have hudson failures (which I see you
    are fixing now), and also the test cases do not check that the results
    are correct (i.e. prefetching is actually working as expected vs.
    simply not throwing an exception). I am a bit uneasy about including
    such a consequential change in 3.0 at this point. Do you think there
    is a more localized workaround, even if it is a hack, for the stable
    branch? But maybe I am too paranoid.
    Since this is expected to be latest milestone,
    It doesn't have to be, although from slow voting on RC2, I guess as a
    practical matter doing yet another RC is too painful for everyone
    involved :-/
    may I ask that you redeploy artifacts after EJBQL issues are
    finished and we test it again?
    Good question. I'd say it depends on what the problem is and whether
    there is a problem. (Do you have time to look at that BTW?) Also we
    have a bunch of EJBQL holes plugged on trunk already, but not on 3.0
    (most notably CAY-1069, but also CAY-1366 now in progress). So we have
    a choice of further delaying 3.0, treating those as "known
    limitations", or something in between - fixing them in 3.0.1...

    Based on the past history of major releases (1.0, 1.1, 1.2) I was a
    bit skeptical about us being able to go from Alpha to final in just a
    couple of months. The thing just has to settle down and stabilize.
    Which means responding to bug reports for some time and releasing as
    many RC's as needed. The rate of new Jiras coming in clearly indicates
    that we need more time, unless we adopt a different definition of a
    final release (N.0 is released as "final", but it is really alpha,
    with fixes being done as N.0.1, N.0.2, etc.)

    I tend to agree that we need to recall the vote and redo the files to
    include your fixes (which may not save us from RC3, unless the bug
    reports suddenly stop flowing)... And maybe also include CAY-1069...

    Thoughts?

    Andrus
  • Andrey Razumovsky at Jan 20, 2010 at 10:37 pm
    2010/1/21 Andrus Adamchik <andrus@objectstyle.org>
    On Jan 20, 2010, at 11:26 PM, Andrey Razumovsky wrote:

    CAY-1368 is now fixed, other issues will probably do this week.
    The fix seems to have some global consequences (unsurprisingly, as it
    changes some fundamental methods in DbEntity and ObjEntity). I haven't
    looked at the details, but we do have hudson failures (which I see you are
    fixing now), and also the test cases do not check that the results are
    correct (i.e. prefetching is actually working as expected vs. simply not
    throwing an exception). I am a bit uneasy about including such a
    consequential change in 3.0 at this point. Do you think there is a more
    localized workaround, even if it is a hack, for the stable branch? But maybe
    I am too paranoid.
    The fix is not fundamental at all - it only changes path iterator type
    everywhere so that it treats left joins as well.
    As for new unit tests - yeah, had no time today to create deep tests, just
    checked the generated SQL myself. Maybe will change that later..
    Test failures is just JDK5 craziness (as you can see, it's OK on JDK6).
    While a complex typecast structure compiles successfully it has
    java.lang.Errors in runtime. Changed that to something easier...

    may I ask that you redeploy artifacts after EJBQL issues are finished and
    we test it again?
    Good question. I'd say it depends on what the problem is and whether there
    is a problem. (Do you have time to look at that BTW?) Also we have a bunch
    of EJBQL holes plugged on trunk already, but not on 3.0 (most notably
    CAY-1069, but also CAY-1366 now in progress). So we have a choice of further
    delaying 3.0, treating those as "known limitations", or something in between
    - fixing them in 3.0.1...

    Based on the past history of major releases (1.0, 1.1, 1.2) I was a bit
    skeptical about us being able to go from Alpha to final in just a couple of
    months. The thing just has to settle down and stabilize. Which means
    responding to bug reports for some time and releasing as many RC's as
    needed. The rate of new Jiras coming in clearly indicates that we need more
    time, unless we adopt a different definition of a final release (N.0 is
    released as "final", but it is really alpha, with fixes being done as N.0.1,
    N.0.2, etc.)

    I tend to agree that we need to recall the vote and redo the files to
    include your fixes (which may not save us from RC3, unless the bug reports
    suddenly stop flowing)... And maybe also include CAY-1069...

    Thoughts?
    Agreed
  • Andrus Adamchik at Jan 21, 2010 at 7:34 am

    On Jan 21, 2010, at 12:37 AM, Andrey Razumovsky wrote:

    The fix is not fundamental at all - it only changes path iterator type
    everywhere so that it treats left joins as well.
    As for new unit tests - yeah, had no time today to create deep
    tests, just
    checked the generated SQL myself. Maybe will change that later..
    Test failures is just JDK5 craziness (as you can see, it's OK on
    JDK6).
    While a complex typecast structure compiles successfully it has
    java.lang.Errors in runtime. Changed that to something easier...
    This is what I wanted to hear :-) BTW, the 1.6 trunk Derby build is
    still down for some reason.

    I am recalling the vote and removing the artifacts. I will prepare a
    new set of artifacts in the course of a couple of days.

    Andrus
  • Aristedes Maniatis at Jan 21, 2010 at 2:11 am

    On 21/01/10 9:23 AM, Andrus Adamchik wrote:
    It doesn't have to be, although from slow voting on RC2, I guess as a
    practical matter doing yet another RC is too painful for everyone
    involved :-/
    Or else we could agree that this is "only" a release candidate. That is, everyone on the PMC doesn't have to verify the entire package in detail. We could treat the voting as a formality the PMC needs to go through and say "we trust that Andrus is doing the right thing and there is nothing going into svn which looks like a problem". That way we could release RCs more often (which would be useful), and still spend much more time reviewing the final 3.0 release package.

    Ari

    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
  • Andrus Adamchik at Jan 21, 2010 at 12:39 pm
    I agree. We had B1 seriously evaluated by most (all?) active Cayenne
    developers. So we have a base line. The rate of SVN changes on 3.0-
    STABLE is relatively low. All of the changes are bug fixes and
    documentation. So release evaluation can just focus on a "smoke test",
    legal clearance and checking the commits history. That should
    hopefully take less time compared to say putting a new RC in a
    production environment. The good thing is that the end users will help
    us with deeper quality control, but for that we need to churn the RCs
    quickly.

    Andrus

    On Jan 21, 2010, at 4:11 AM, Aristedes Maniatis wrote:
    On 21/01/10 9:23 AM, Andrus Adamchik wrote:
    It doesn't have to be, although from slow voting on RC2, I guess as a
    practical matter doing yet another RC is too painful for everyone
    involved :-/
    Or else we could agree that this is "only" a release candidate. That
    is, everyone on the PMC doesn't have to verify the entire package in
    detail. We could treat the voting as a formality the PMC needs to go
    through and say "we trust that Andrus is doing the right thing and
    there is nothing going into svn which looks like a problem". That
    way we could release RCs more often (which would be useful), and
    still spend much more time reviewing the final 3.0 release package.

    Ari

    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedJan 17, '10 at 3:39p
activeJan 21, '10 at 12:39p
posts7
users3
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase