FAQ

[Struts-dev] [VOTE] Struts 2.0.5 Quality

Ted Husted
Feb 5, 2007 at 6:11 pm
The Struts 2.0.5 test build is now available.

Release notes:
* http://struts.apache.org/2.x/docs/release-notes-205.html

Distribution:
* http://people.apache.org/builds/struts/2.0.5/

Maven 2 staging repository:
* http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/

If you have had a chance to review the test build, please respond with
a vote on its quality:

[ ] Leave at test build
[ ] Alpha
[ ] Beta
[ ] General Availability (GA)

Everyone who has tested the build is invited to vote. Votes by PMC
members are considered binding. A vote passes if there are at least
three binding +1s and more +1s than -1s.

Please remember that a *binding* +1 for GA implies that you intend to
support the release by applying patches and responding to posts to the
user and dev lists.

The vote will remain open for at least 72 hours, longer upon request.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
reply

Search Discussions

41 responses

  • Mraible at Feb 6, 2007 at 8:03 am

    Ted Husted-3 wrote:

    The Struts 2.0.5 test build is now available.

    Release notes:
    * http://struts.apache.org/2.x/docs/release-notes-205.html

    Distribution:
    * http://people.apache.org/builds/struts/2.0.5/

    Maven 2 staging repository:
    * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/

    If you have had a chance to review the test build, please respond with
    a vote on its quality:
    Tested with AppFuse 2:

    [ ] Leave at test build
    [ ] Alpha
    [ ] Beta
    [X] General Availability (GA)

    Non-binding.

    Matt


    --
    View this message in context: http://www.nabble.com/-VOTE--Struts-2.0.5-Quality-tf3175941.html#a8821923
    Sent from the Struts - Dev mailing list archive at Nabble.com.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Patrick Lightbody at Feb 6, 2007 at 6:31 pm
    +1 for GA - I'm using it in HostedQA now and it is working great.
    ---------------------------------------------------------------------
    Posted via Jive Forums
    http://forums.opensymphony.com/thread.jspa?threadID=62617&messageID=121464#121464


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Ian Roughley at Feb 6, 2007 at 8:11 pm
    +0 for GA. I have some testing code that looks good, but no production
    code that has been converted.

    /Ian

    Ted Husted wrote:
    The Struts 2.0.5 test build is now available.

    Release notes:
    * http://struts.apache.org/2.x/docs/release-notes-205.html

    Distribution:
    * http://people.apache.org/builds/struts/2.0.5/

    Maven 2 staging repository:
    * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/

    If you have had a chance to review the test build, please respond with
    a vote on its quality:

    [ ] Leave at test build
    [ ] Alpha
    [ ] Beta
    [ ] General Availability (GA)

    Everyone who has tested the build is invited to vote. Votes by PMC
    members are considered binding. A vote passes if there are at least
    three binding +1s and more +1s than -1s.

    Please remember that a *binding* +1 for GA implies that you intend to
    support the release by applying patches and responding to posts to the
    user and dev lists.

    The vote will remain open for at least 72 hours, longer upon request.

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Ted Husted at Feb 6, 2007 at 10:02 pm
    Beta is also an option :)
    On 2/6/07, Ian Roughley wrote:
    +0 for GA. I have some testing code that looks good, but no production
    code that has been converted.

    /Ian
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Don Brown at Feb 6, 2007 at 10:10 pm
    I disagree; you shouldn't vote beta just because you haven't ran the
    code in production. A beta vote should be reserved for the case where
    you don't believe the quality is at the level of a GA release, and there
    should be specific issues you can point to that you feel need to be
    resolved first. If you have downloaded the release, ran it through
    whatever tests you deem appropriate, and it passes with flying colors,
    then a GA vote is warranted.

    Don

    Ted Husted wrote:
    Beta is also an option :)
    On 2/6/07, Ian Roughley wrote:
    +0 for GA. I have some testing code that looks good, but no production
    code that has been converted.

    /Ian
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Ted Husted at Feb 6, 2007 at 11:25 pm
    We might have to agree to disagree. I believe a beta vote is warranted
    when someone believes the code is ready for testing outside of the
    development group. Personally, I am not in favor of passing a set of
    bits straight to GA without a beta cycle, especially when a release
    series hasn't seen a GA release yet. The term "General Availability"
    should mean that we feel it is ready for us by the general public, not
    just that we were able to use it ourselves. Of course, other PMC
    members may have different viewpoints.

    Remember, voting beta now is not the final disposition. It simply
    means that we can announce the release to the user list and encourage
    wider testing. If the reports come back joyful, then we can decide to
    apply the GA stamp.

    In the meantime, we can continue to roll new releases. I'd be happy to
    run one every week or two, so long as there is something to put into
    the notes :)

    -Ted.
    On 2/6/07, Don Brown wrote:
    I disagree; you shouldn't vote beta just because you haven't ran the
    code in production. A beta vote should be reserved for the case where
    you don't believe the quality is at the level of a GA release, and there
    should be specific issues you can point to that you feel need to be
    resolved first. If you have downloaded the release, ran it through
    whatever tests you deem appropriate, and it passes with flying colors,
    then a GA vote is warranted.

    Don

    Ted Husted wrote:
    Beta is also an option :)
    On 2/6/07, Ian Roughley wrote:
    +0 for GA. I have some testing code that looks good, but no production
    code that has been converted.

    /Ian
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Don Brown at Feb 6, 2007 at 11:42 pm
    Well, two comments here. First, how many beta releases do we need
    before it is time for a GA? I think we've been at beta quality since
    2.0.1 and, yes, it has been helpful to weed out issues, but now with
    several large applications running Struts 2 and no significant issues in
    JIRA, I think we are ready for GA.

    The second is a general comment about this new release process. I think
    you are right that we'll have to agree to disagree here, cause I've
    always disliked this idea of doing a release then voting on it later.
    If we are taking that backwards-looking approach even farther and
    basically automatically giving releases a "beta" label until some
    undetermined future date when we vote again, then I really must object.

    I can understand the value of a test build and vote a few days after to
    ensure that the release process went off smoothly and all the important
    bits are in there. I may not particularly like it, but I agree it is
    necessary. What I find disturbing is that we would make a habit of
    waiting till weeks/months after the fact to label it GA. If the release
    is built, we test it and find nothing wrong, I think we should label it
    GA and move on. If bugs are found after the fact, then let's roll
    another release. I'm concerned that the backwards-looking way of
    thinking will result in a project that very rarely gets anything out to
    its users. I think open source projects work best when they release
    early and often, even if they may find bugs in it later on. And before
    the comment is made that test builds or even beta releases _are_
    following the release early/often pattern, it certainly isn't true for
    what I'd argue that is the majority of developers who can't touch a
    product without the GA label.

    I really hope we can find a productive balance between the need for
    stability and need to keep the project moving at a healthy pace. Let's
    not fall into the Struts 1 trap of being overly conservative, but
    instead get out quality releases quickly and often.

    Don
    Ted Husted wrote:
    We might have to agree to disagree. I believe a beta vote is warranted
    when someone believes the code is ready for testing outside of the
    development group. Personally, I am not in favor of passing a set of
    bits straight to GA without a beta cycle, especially when a release
    series hasn't seen a GA release yet. The term "General Availability"
    should mean that we feel it is ready for us by the general public, not
    just that we were able to use it ourselves. Of course, other PMC
    members may have different viewpoints.

    Remember, voting beta now is not the final disposition. It simply
    means that we can announce the release to the user list and encourage
    wider testing. If the reports come back joyful, then we can decide to
    apply the GA stamp.

    In the meantime, we can continue to roll new releases. I'd be happy to
    run one every week or two, so long as there is something to put into
    the notes :)

    -Ted.
    On 2/6/07, Don Brown wrote:
    I disagree; you shouldn't vote beta just because you haven't ran the
    code in production. A beta vote should be reserved for the case where
    you don't believe the quality is at the level of a GA release, and there
    should be specific issues you can point to that you feel need to be
    resolved first. If you have downloaded the release, ran it through
    whatever tests you deem appropriate, and it passes with flying colors,
    then a GA vote is warranted.

    Don

    Ted Husted wrote:
    Beta is also an option :)
    On 2/6/07, Ian Roughley wrote:
    +0 for GA. I have some testing code that looks good, but no
    production
    code that has been converted.

    /Ian
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Craig McClanahan at Feb 6, 2007 at 11:54 pm

    On 2/6/07, Don Brown wrote:
    Well, two comments here. First, how many beta releases do we need
    before it is time for a GA? I think we've been at beta quality since
    2.0.1 and, yes, it has been helpful to weed out issues, but now with
    several large applications running Struts 2 and no significant issues in
    JIRA, I think we are ready for GA.

    The second is a general comment about this new release process. I think
    you are right that we'll have to agree to disagree here, cause I've
    always disliked this idea of doing a release then voting on it later.
    If we are taking that backwards-looking approach even farther and
    basically automatically giving releases a "beta" label until some
    undetermined future date when we vote again, then I really must object.

    I can understand the value of a test build and vote a few days after to
    ensure that the release process went off smoothly and all the important
    bits are in there. I may not particularly like it, but I agree it is
    necessary. What I find disturbing is that we would make a habit of
    waiting till weeks/months after the fact to label it GA. If the release
    is built, we test it and find nothing wrong, I think we should label it
    GA and move on. If bugs are found after the fact, then let's roll
    another release. I'm concerned that the backwards-looking way of
    thinking will result in a project that very rarely gets anything out to
    its users. I think open source projects work best when they release
    early and often, even if they may find bugs in it later on. And before
    the comment is made that test builds or even beta releases _are_
    following the release early/often pattern, it certainly isn't true for
    what I'd argue that is the majority of developers who can't touch a
    product without the GA label.

    I really hope we can find a productive balance between the need for
    stability and need to keep the project moving at a healthy pace. Let's
    not fall into the Struts 1 trap of being overly conservative, but
    instead get out quality releases quickly and often.

    Isn't a feature of the current release practice that you could vote a
    particular x.y.z release as "beta" now, but later hold another vote to
    upgrade it to GA status later (i.e. without requiring another release)?
    Don's success with it is great ... but that is only one data point. Having
    10-50 people report back success would seem to mean it's time to go back and
    give that release a better report card.


    Don


    Craig


    Ted Husted wrote:
    We might have to agree to disagree. I believe a beta vote is warranted
    when someone believes the code is ready for testing outside of the
    development group. Personally, I am not in favor of passing a set of
    bits straight to GA without a beta cycle, especially when a release
    series hasn't seen a GA release yet. The term "General Availability"
    should mean that we feel it is ready for us by the general public, not
    just that we were able to use it ourselves. Of course, other PMC
    members may have different viewpoints.

    Remember, voting beta now is not the final disposition. It simply
    means that we can announce the release to the user list and encourage
    wider testing. If the reports come back joyful, then we can decide to
    apply the GA stamp.

    In the meantime, we can continue to roll new releases. I'd be happy to
    run one every week or two, so long as there is something to put into
    the notes :)

    -Ted.
    On 2/6/07, Don Brown wrote:
    I disagree; you shouldn't vote beta just because you haven't ran the
    code in production. A beta vote should be reserved for the case where
    you don't believe the quality is at the level of a GA release, and
    there
    should be specific issues you can point to that you feel need to be
    resolved first. If you have downloaded the release, ran it through
    whatever tests you deem appropriate, and it passes with flying colors,
    then a GA vote is warranted.

    Don

    Ted Husted wrote:
    Beta is also an option :)
    On 2/6/07, Ian Roughley wrote:
    +0 for GA. I have some testing code that looks good, but no
    production
    code that has been converted.

    /Ian
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Alexandru Popescu at Feb 7, 2007 at 12:17 am

    On 2/7/07, Craig McClanahan wrote:
    On 2/6/07, Don Brown wrote:

    Well, two comments here. First, how many beta releases do we need
    before it is time for a GA? I think we've been at beta quality since
    2.0.1 and, yes, it has been helpful to weed out issues, but now with
    several large applications running Struts 2 and no significant issues in
    JIRA, I think we are ready for GA.

    The second is a general comment about this new release process. I think
    you are right that we'll have to agree to disagree here, cause I've
    always disliked this idea of doing a release then voting on it later.
    If we are taking that backwards-looking approach even farther and
    basically automatically giving releases a "beta" label until some
    undetermined future date when we vote again, then I really must object.

    I can understand the value of a test build and vote a few days after to
    ensure that the release process went off smoothly and all the important
    bits are in there. I may not particularly like it, but I agree it is
    necessary. What I find disturbing is that we would make a habit of
    waiting till weeks/months after the fact to label it GA. If the release
    is built, we test it and find nothing wrong, I think we should label it
    GA and move on. If bugs are found after the fact, then let's roll
    another release. I'm concerned that the backwards-looking way of
    thinking will result in a project that very rarely gets anything out to
    its users. I think open source projects work best when they release
    early and often, even if they may find bugs in it later on. And before
    the comment is made that test builds or even beta releases _are_
    following the release early/often pattern, it certainly isn't true for
    what I'd argue that is the majority of developers who can't touch a
    product without the GA label.

    I really hope we can find a productive balance between the need for
    stability and need to keep the project moving at a healthy pace. Let's
    not fall into the Struts 1 trap of being overly conservative, but
    instead get out quality releases quickly and often.

    Isn't a feature of the current release practice that you could vote a
    particular x.y.z release as "beta" now, but later hold another vote to
    upgrade it to GA status later (i.e. without requiring another release)?
    Don's success with it is great ... but that is only one data point. Having
    10-50 people report back success would seem to mean it's time to go back and
    give that release a better report card.


    Don


    Craig


    Ted Husted wrote:
    We might have to agree to disagree. I believe a beta vote is warranted
    when someone believes the code is ready for testing outside of the
    development group. Personally, I am not in favor of passing a set of
    bits straight to GA without a beta cycle, especially when a release
    series hasn't seen a GA release yet. The term "General Availability"
    should mean that we feel it is ready for us by the general public, not
    just that we were able to use it ourselves. Of course, other PMC
    members may have different viewpoints.

    Remember, voting beta now is not the final disposition. It simply
    means that we can announce the release to the user list and encourage
    wider testing. If the reports come back joyful, then we can decide to
    apply the GA stamp.

    In the meantime, we can continue to roll new releases. I'd be happy to
    run one every week or two, so long as there is something to put into
    the notes :)

    -Ted.
    I see two clear stages:

    - a product that is ready from developers point of view
    - a product that gets its users acceptance

    An OSS project can take the same approach or not, and this is up to
    its management. However, I feel that a project that would like to be
    widely used cannot be labeled as released version without the user
    acceptance.

    I understand Don's concern about how these steps should be managed,
    but I think this is not a very complex process:

    - developer's ready version: beta
    - (after a scheduled period during which only fixes go in if necessary): GA.

    ./alex
    --
    .w( the_mindstorm )p.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Don Brown at Feb 7, 2007 at 1:05 am

    Alexandru Popescu wrote:
    I see two clear stages:

    - a product that is ready from developers point of view
    - a product that gets its users acceptance

    An OSS project can take the same approach or not, and this is up to
    its management. However, I feel that a project that would like to be
    widely used cannot be labeled as released version without the user
    acceptance.

    I understand Don's concern about how these steps should be managed,
    but I think this is not a very complex process:

    - developer's ready version: beta
    - (after a scheduled period during which only fixes go in if
    necessary): GA.
    I would love it if we actually did this. Unfortunately, we don't do the
    second step, which is to have a scheduled period that allows fixes to go
    in if necessary. What we actually do is freeze the code in a test
    build, and put that through an undetermined period after which it may be
    reassessed. If any problems are found after the build, the whole
    process starts again. What this results in is a project that very, very
    rarely releases a GA release because issues are always found after the
    test build. If you don't believe me, look how often we put GA releases
    out with Struts 1 and that was with a code base that rarely saw any
    significant development/features. Imagine how long it would take us to
    get out a release on a very active project...

    Don

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Ted Husted at Feb 7, 2007 at 1:28 am

    On 2/6/07, Don Brown wrote:
    I would love it if we actually did this. Unfortunately, we don't do the
    second step, which is to have a scheduled period that allows fixes to go
    in if necessary. What we actually do is freeze the code in a test
    build, and put that through an undetermined period after which it may be
    reassessed. If any problems are found after the build, the whole
    process starts again. What this results in is a project that very, very
    rarely releases a GA release because issues are always found after the
    test build. If you don't believe me, look how often we put GA releases
    out with Struts 1 and that was with a code base that rarely saw any
    significant development/features. Imagine how long it would take us to
    get out a release on a very active project...

    We did the second steps several times with Struts 1.2.x. As to Struts
    2.0.x, so far, 2.0.2 has been our one and only beta. Every other build
    has failed for reasons unrelated to quality.

    * 2.0.0 (24/Sep) - Early test build against XWork snapshot.

    * 2.0.1 (11/Oct) - Test build against XWork beta 1.

    * 2.0.2 (20/Oct) - Voted beta, mainly due to XWork beta status (which
    in turn was due to documentation issues, rather than code quality).

    * 2.0.3 (19/Jan) - Stayed at test status due to Maven build issues.

    * 2.0.4 (28/Jan) - Tabled at test build, mainly for
    documentation/licensing issues.

    * 2.0.5 (05/Feb) - Current build.

    IMHO, what hurt us was that we had to roll 2.0.2 against a XWork beta,
    and then we made aggressive changes to the codebases. Now that XWork
    is GA, we had four months of very active development, and gobs of new
    features that were not in the 2.0.2 release. If 2.0.2 had been able to
    go GA, I'd be suggesting that we roll over to the 2.1.x series.

    Of course, there are and will be issues with 2.0.5. There are always
    issues. But, that doesn't mean we can't vote it GA after we've given
    the rest of the community a bite at the apple. The question isn't
    whether we reach an arbitrary standard of quality, but whether other
    people are going to say "Works for me!"

    During the Struts 1.1.x series, we did tend to freeze the codebase,
    but I don't feel that we do that any more. I feel that 2.0.5 is
    tagged, and we can move on to 2.0.6, full steam ahead, and/or 2.1.x if
    someone is ready to work on the Dojo and Portlet plugins.

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Mraible at Feb 7, 2007 at 6:30 am
    I'm with Don here - IMO, Struts 2.0.1 was been usable for the general public
    and the subsequent releases are all a result of Apache politics (or
    Mavenisms).

    ;-)

    Matt


    Ted Husted-3 wrote:
    On 2/6/07, Don Brown wrote:
    I would love it if we actually did this. Unfortunately, we don't do the
    second step, which is to have a scheduled period that allows fixes to go
    in if necessary. What we actually do is freeze the code in a test
    build, and put that through an undetermined period after which it may be
    reassessed. If any problems are found after the build, the whole
    process starts again. What this results in is a project that very, very
    rarely releases a GA release because issues are always found after the
    test build. If you don't believe me, look how often we put GA releases
    out with Struts 1 and that was with a code base that rarely saw any
    significant development/features. Imagine how long it would take us to
    get out a release on a very active project...

    We did the second steps several times with Struts 1.2.x. As to Struts
    2.0.x, so far, 2.0.2 has been our one and only beta. Every other build
    has failed for reasons unrelated to quality.

    * 2.0.0 (24/Sep) - Early test build against XWork snapshot.

    * 2.0.1 (11/Oct) - Test build against XWork beta 1.

    * 2.0.2 (20/Oct) - Voted beta, mainly due to XWork beta status (which
    in turn was due to documentation issues, rather than code quality).

    * 2.0.3 (19/Jan) - Stayed at test status due to Maven build issues.

    * 2.0.4 (28/Jan) - Tabled at test build, mainly for
    documentation/licensing issues.

    * 2.0.5 (05/Feb) - Current build.

    IMHO, what hurt us was that we had to roll 2.0.2 against a XWork beta,
    and then we made aggressive changes to the codebases. Now that XWork
    is GA, we had four months of very active development, and gobs of new
    features that were not in the 2.0.2 release. If 2.0.2 had been able to
    go GA, I'd be suggesting that we roll over to the 2.1.x series.

    Of course, there are and will be issues with 2.0.5. There are always
    issues. But, that doesn't mean we can't vote it GA after we've given
    the rest of the community a bite at the apple. The question isn't
    whether we reach an arbitrary standard of quality, but whether other
    people are going to say "Works for me!"

    During the Struts 1.1.x series, we did tend to freeze the codebase,
    but I don't feel that we do that any more. I feel that 2.0.5 is
    tagged, and we can move on to 2.0.6, full steam ahead, and/or 2.1.x if
    someone is ready to work on the Dojo and Portlet plugins.

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org

    --
    View this message in context: http://www.nabble.com/-VOTE--Struts-2.0.5-Quality-tf3175941.html#a8840543
    Sent from the Struts - Dev mailing list archive at Nabble.com.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Ted Husted at Feb 7, 2007 at 11:25 am

    On 2/7/07, mraible wrote:
    I'm with Don here - IMO, Struts 2.0.1 was been usable for the general public
    True. And if we had a stable release of XWork 2 in September, I
    believe that we would have marked 2.0.1 GA.
    and the subsequent releases are all a result of Apache politics (or
    Mavenisms).
    Until January 8, when XWork 2.0.0 was released, none of the other
    builds were eligible for non-beta status, because XW was beta. There
    were other issues with the builds, but we would have worked around
    those very quickly if a GA had even been possible. (As we did for
    2.0.4 and 2.0.5.)

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Craig McClanahan at Feb 7, 2007 at 6:07 am

    On 2/6/07, Don Brown wrote:
    Alexandru Popescu wrote:
    I see two clear stages:

    - a product that is ready from developers point of view
    - a product that gets its users acceptance

    An OSS project can take the same approach or not, and this is up to
    its management. However, I feel that a project that would like to be
    widely used cannot be labeled as released version without the user
    acceptance.

    I understand Don's concern about how these steps should be managed,
    but I think this is not a very complex process:

    - developer's ready version: beta
    - (after a scheduled period during which only fixes go in if
    necessary): GA.
    I would love it if we actually did this. Unfortunately, we don't do the
    second step, which is to have a scheduled period that allows fixes to go
    in if necessary. What we actually do is freeze the code in a test
    build, and put that through an undetermined period after which it may be
    reassessed. If any problems are found after the build, the whole
    process starts again. What this results in is a project that very, very
    rarely releases a GA release because issues are always found after the
    test build. If you don't believe me, look how often we put GA releases
    out with Struts 1 and that was with a code base that rarely saw any
    significant development/features. Imagine how long it would take us to
    get out a release on a very active project...

    That is definitely one of the lessons to be learned from the Struts
    1.xexperience. Here's how we're applying that lesson in Shale land.
    The
    recent 1.0.4 release is the first one we felt had a snowball's chance at
    being voted GA quality, so as soon as we cut that release we also branched
    (SHALE_1_0_X), with the rule that only bugfixes (including non-invasive
    bugfixes backported from the trunk) would be committed here. The trunk was
    then opened for further "new feature" development (as well as bugfixes).
    Right now, it is tentatively labelled as "1.1.0-SNAPSHOT", but that could
    easily become 2.0.0-SNAPSHOT if we wanted to do major
    non-backwards-compatible changes.

    The net effect is that Struts could:

    * Create a branch totally focused on stabilization and bugfixes ... the only
    *point*
    is to create a GA-quality branch based on the current feature set. If
    2.0.5 does not
    cut the mustard, just fix the reported bugs and try again (weeks instead
    of years later).

    * Avoid slowing down new feature development ... it continues on the trunk.

    * If 2.05 (say) got voted GA but a security vulnerability or critical bug
    were later
    discovered, an updated version could be turned around VERY quickly on the
    branch. Just fix the bad problems and release it. You don't have to
    worry about
    stabilizing all the new features that might have been added on the trunk,
    because
    they won't be present on the branch. (The MyFaces folks are currently
    paying
    the same price we paid in 1.x, because they are intermixing new features
    and
    bugfixes on the trunk -- hopefully they will learn the same lesson.)

    Branches are our friends. The fact that we didn't leverage them is the
    biggest thing we did wrong in Struts 1.x development, IMHO. I hope that the
    Struts 2 process can improve based on lessons learned from that experience.

    Don


    Craig
  • Rene Gielen at Feb 7, 2007 at 7:37 am
    Craig,

    So feature freeze and branch 2.0.x now, only fix reported bugs from beta
    tests and roll out the result as GA, while trunk moves on to 2.1.x,
    fully open for new features and whatever? IMO this would be the perfect
    way to go, you get a big +1 from me on this :)

    - Rene

    Craig McClanahan schrieb:
    On 2/6/07, Don Brown wrote:

    Alexandru Popescu wrote:
    I see two clear stages:

    - a product that is ready from developers point of view
    - a product that gets its users acceptance

    [...]

    That is definitely one of the lessons to be learned from the Struts
    1.xexperience. Here's how we're applying that lesson in Shale land.
    The
    recent 1.0.4 release is the first one we felt had a snowball's chance at
    being voted GA quality, so as soon as we cut that release we also branched
    (SHALE_1_0_X), with the rule that only bugfixes (including non-invasive
    bugfixes backported from the trunk) would be committed here. The trunk was
    then opened for further "new feature" development (as well as bugfixes).
    Right now, it is tentatively labelled as "1.1.0-SNAPSHOT", but that could
    easily become 2.0.0-SNAPSHOT if we wanted to do major
    non-backwards-compatible changes.

    The net effect is that Struts could:

    * Create a branch totally focused on stabilization and bugfixes ... the
    only
    *point*
    is to create a GA-quality branch based on the current feature set. If
    2.0.5 does not
    cut the mustard, just fix the reported bugs and try again (weeks instead
    of years later).

    * Avoid slowing down new feature development ... it continues on the trunk.

    * If 2.05 (say) got voted GA but a security vulnerability or critical bug
    were later
    discovered, an updated version could be turned around VERY quickly on the
    branch. Just fix the bad problems and release it. You don't have to
    worry about
    stabilizing all the new features that might have been added on the trunk,
    because
    they won't be present on the branch. (The MyFaces folks are currently
    paying
    the same price we paid in 1.x, because they are intermixing new features
    and
    bugfixes on the trunk -- hopefully they will learn the same lesson.)

    Branches are our friends. The fact that we didn't leverage them is the
    biggest thing we did wrong in Struts 1.x development, IMHO. I hope that
    the
    Struts 2 process can improve based on lessons learned from that experience.

    Don


    Craig
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Philip Luppens at Feb 7, 2007 at 8:38 am

    On 2/7/07, Rene Gielen wrote:
    Craig,

    So feature freeze and branch 2.0.x now, only fix reported bugs from beta
    tests and roll out the result as GA, while trunk moves on to 2.1.x,
    fully open for new features and whatever? IMO this would be the perfect
    way to go, you get a big +1 from me on this :)

    - Rene
    +1
    I totally agree with this.
    Craig McClanahan schrieb:
    On 2/6/07, Don Brown wrote:

    Alexandru Popescu wrote:
    I see two clear stages:

    - a product that is ready from developers point of view
    - a product that gets its users acceptance

    [...]

    That is definitely one of the lessons to be learned from the Struts
    1.xexperience. Here's how we're applying that lesson in Shale land.
    The
    recent 1.0.4 release is the first one we felt had a snowball's chance at
    being voted GA quality, so as soon as we cut that release we also branched
    (SHALE_1_0_X), with the rule that only bugfixes (including non-invasive
    bugfixes backported from the trunk) would be committed here. The trunk was
    then opened for further "new feature" development (as well as bugfixes).
    Right now, it is tentatively labelled as "1.1.0-SNAPSHOT", but that could
    easily become 2.0.0-SNAPSHOT if we wanted to do major
    non-backwards-compatible changes.

    The net effect is that Struts could:

    * Create a branch totally focused on stabilization and bugfixes ... the
    only
    *point*
    is to create a GA-quality branch based on the current feature set. If
    2.0.5 does not
    cut the mustard, just fix the reported bugs and try again (weeks instead
    of years later).

    * Avoid slowing down new feature development ... it continues on the trunk.

    * If 2.05 (say) got voted GA but a security vulnerability or critical bug
    were later
    discovered, an updated version could be turned around VERY quickly on the
    branch. Just fix the bad problems and release it. You don't have to
    worry about
    stabilizing all the new features that might have been added on the trunk,
    because
    they won't be present on the branch. (The MyFaces folks are currently
    paying
    the same price we paid in 1.x, because they are intermixing new features
    and
    bugfixes on the trunk -- hopefully they will learn the same lesson.)

    Branches are our friends. The fact that we didn't leverage them is the
    biggest thing we did wrong in Struts 1.x development, IMHO. I hope that
    the
    Struts 2 process can improve based on lessons learned from that experience.

    Don


    Craig
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org

    --
    iDTV System Engineer
    "Always code as if the guy who ends up maintaining your code will be a
    violent psychopath who knows where you live." - John F. Woods

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Alexandru Popescu at Feb 7, 2007 at 11:38 am

    On 2/7/07, Philip Luppens wrote:
    On 2/7/07, Rene Gielen wrote:
    Craig,

    So feature freeze and branch 2.0.x now, only fix reported bugs from beta
    tests and roll out the result as GA, while trunk moves on to 2.1.x,
    fully open for new features and whatever? IMO this would be the perfect
    way to go, you get a big +1 from me on this :)

    - Rene
    +1
    I totally agree with this.
    Full +1 for this.

    ./alex
    --
    .w( the_mindstorm )p.
    Craig McClanahan schrieb:
    On 2/6/07, Don Brown wrote:

    Alexandru Popescu wrote:
    I see two clear stages:

    - a product that is ready from developers point of view
    - a product that gets its users acceptance

    [...]

    That is definitely one of the lessons to be learned from the Struts
    1.xexperience. Here's how we're applying that lesson in Shale land.
    The
    recent 1.0.4 release is the first one we felt had a snowball's chance at
    being voted GA quality, so as soon as we cut that release we also branched
    (SHALE_1_0_X), with the rule that only bugfixes (including non-invasive
    bugfixes backported from the trunk) would be committed here. The trunk was
    then opened for further "new feature" development (as well as bugfixes).
    Right now, it is tentatively labelled as "1.1.0-SNAPSHOT", but that could
    easily become 2.0.0-SNAPSHOT if we wanted to do major
    non-backwards-compatible changes.

    The net effect is that Struts could:

    * Create a branch totally focused on stabilization and bugfixes ... the
    only
    *point*
    is to create a GA-quality branch based on the current feature set. If
    2.0.5 does not
    cut the mustard, just fix the reported bugs and try again (weeks instead
    of years later).

    * Avoid slowing down new feature development ... it continues on the trunk.

    * If 2.05 (say) got voted GA but a security vulnerability or critical bug
    were later
    discovered, an updated version could be turned around VERY quickly on the
    branch. Just fix the bad problems and release it. You don't have to
    worry about
    stabilizing all the new features that might have been added on the trunk,
    because
    they won't be present on the branch. (The MyFaces folks are currently
    paying
    the same price we paid in 1.x, because they are intermixing new features
    and
    bugfixes on the trunk -- hopefully they will learn the same lesson.)

    Branches are our friends. The fact that we didn't leverage them is the
    biggest thing we did wrong in Struts 1.x development, IMHO. I hope that
    the
    Struts 2 process can improve based on lessons learned from that experience.

    Don


    Craig
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org

    --
    iDTV System Engineer
    "Always code as if the guy who ends up maintaining your code will be a
    violent psychopath who knows where you live." - John F. Woods

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • David H. DeWolf at Feb 7, 2007 at 12:32 pm

    Rene Gielen wrote:
    Craig,

    So feature freeze and branch 2.0.x now, only fix reported bugs from beta
    tests and roll out the result as GA, while trunk moves on to 2.1.x,
    fully open for new features and whatever? IMO this would be the perfect
    way to go, you get a big +1 from me on this :)
    +1 As well.
    - Rene

    Craig McClanahan schrieb:
    On 2/6/07, Don Brown wrote:
    Alexandru Popescu wrote:
    I see two clear stages:

    - a product that is ready from developers point of view
    - a product that gets its users acceptance

    [...]
    That is definitely one of the lessons to be learned from the Struts
    1.xexperience. Here's how we're applying that lesson in Shale land.
    The
    recent 1.0.4 release is the first one we felt had a snowball's chance at
    being voted GA quality, so as soon as we cut that release we also branched
    (SHALE_1_0_X), with the rule that only bugfixes (including non-invasive
    bugfixes backported from the trunk) would be committed here. The trunk was
    then opened for further "new feature" development (as well as bugfixes).
    Right now, it is tentatively labelled as "1.1.0-SNAPSHOT", but that could
    easily become 2.0.0-SNAPSHOT if we wanted to do major
    non-backwards-compatible changes.

    The net effect is that Struts could:

    * Create a branch totally focused on stabilization and bugfixes ... the
    only
    *point*
    is to create a GA-quality branch based on the current feature set. If
    2.0.5 does not
    cut the mustard, just fix the reported bugs and try again (weeks instead
    of years later).

    * Avoid slowing down new feature development ... it continues on the trunk.

    * If 2.05 (say) got voted GA but a security vulnerability or critical bug
    were later
    discovered, an updated version could be turned around VERY quickly on the
    branch. Just fix the bad problems and release it. You don't have to
    worry about
    stabilizing all the new features that might have been added on the trunk,
    because
    they won't be present on the branch. (The MyFaces folks are currently
    paying
    the same price we paid in 1.x, because they are intermixing new features
    and
    bugfixes on the trunk -- hopefully they will learn the same lesson.)

    Branches are our friends. The fact that we didn't leverage them is the
    biggest thing we did wrong in Struts 1.x development, IMHO. I hope that
    the
    Struts 2 process can improve based on lessons learned from that experience.

    Don


    Craig
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Ted Husted at Feb 7, 2007 at 1:01 am

    On 2/6/07, Craig McClanahan wrote:
    Isn't a feature of the current release practice that you could vote a
    particular x.y.z release as "beta" now, but later hold another vote to
    upgrade it to GA status later (i.e. without requiring another release)?
    Don's success with it is great ... but that is only one data point. Having
    10-50 people report back success would seem to mean it's time to go back and
    give that release a better report card.

    Craig
    Yes, it is, and we've used the approach successfully with Struts 1.x.
    It's nothing new. We've been using it for years, and so has HTTPD, and
    Tomcat, and dozens of other projects.

    Voting 2.0.5 beta now doesn't mean that it will stay at beta. It just
    means that we will release it to the user list for wider testing. If
    the user testing goes well, we can just promote 2.0.5 to GA, and
    announce it again. Nothing changes except our opinion.

    In the meantime, we can continue to make fixes and add features, and
    roll 2.0.6 as soon as we like. Hopefully, 2.0.5 will go GA, and so
    will 2.0.6. We had several GA releases in the 1.2.x series.

    One thing I tried this time was to post the Quality vote the day the
    test build went up. Next time, I'd like to try rolling on a Thursday,
    so that we can hold the vote over the weekend, and maybe announce on
    Monday.

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Alexandru Popescu at Feb 7, 2007 at 12:10 am
    I fully agree with Ted's explanation of vote meanings so
    [ ] Leave at test build
    [ ] Alpha
    [ x] Beta
    [ ] General Availability (GA)
    ./alex
    --
    .w( the_mindstorm )p.

    On 2/7/07, Ted Husted wrote:
    We might have to agree to disagree. I believe a beta vote is warranted
    when someone believes the code is ready for testing outside of the
    development group. Personally, I am not in favor of passing a set of
    bits straight to GA without a beta cycle, especially when a release
    series hasn't seen a GA release yet. The term "General Availability"
    should mean that we feel it is ready for us by the general public, not
    just that we were able to use it ourselves. Of course, other PMC
    members may have different viewpoints.

    Remember, voting beta now is not the final disposition. It simply
    means that we can announce the release to the user list and encourage
    wider testing. If the reports come back joyful, then we can decide to
    apply the GA stamp.

    In the meantime, we can continue to roll new releases. I'd be happy to
    run one every week or two, so long as there is something to put into
    the notes :)

    -Ted.
    On 2/6/07, Don Brown wrote:
    I disagree; you shouldn't vote beta just because you haven't ran the
    code in production. A beta vote should be reserved for the case where
    you don't believe the quality is at the level of a GA release, and there
    should be specific issues you can point to that you feel need to be
    resolved first. If you have downloaded the release, ran it through
    whatever tests you deem appropriate, and it passes with flying colors,
    then a GA vote is warranted.

    Don

    Ted Husted wrote:
    Beta is also an option :)
    On 2/6/07, Ian Roughley wrote:
    +0 for GA. I have some testing code that looks good, but no production
    code that has been converted.

    /Ian
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Philip Luppens at Feb 7, 2007 at 8:30 am
    I was hoping after 2.0.4 that the ognl race condition issue would have
    been resolved. Jesse is ready to push the release out probably this
    evening, but give it a couple of days. For me, 2.0.5 came a bit too
    soon after 2.0.4. But overal, I think the framework itself is ready
    for GA.
    [ ] Leave at test build
    [ ] Alpha
    [ ] Beta
    [x] General Availability (GA)
    Cheers,

    Phil
    On 2/6/07, Don Brown wrote:
    I disagree; you shouldn't vote beta just because you haven't ran the
    code in production. A beta vote should be reserved for the case where
    you don't believe the quality is at the level of a GA release, and there
    should be specific issues you can point to that you feel need to be
    resolved first. If you have downloaded the release, ran it through
    whatever tests you deem appropriate, and it passes with flying colors,
    then a GA vote is warranted.

    Don

    Ted Husted wrote:
    Beta is also an option :)
    On 2/6/07, Ian Roughley wrote:
    +0 for GA. I have some testing code that looks good, but no production
    code that has been converted.

    /Ian
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org

    --
    iDTV System Engineer
    "Always code as if the guy who ends up maintaining your code will be a
    violent psychopath who knows where you live." - John F. Woods

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Rene Gielen at Feb 6, 2007 at 11:58 pm
    I'm going to do more testing this week, but I think (fear?) I have a
    first opinion so far:
    [ ] Leave at test build
    [ ] Alpha
    [ x] Beta
    [ ] General Availability (GA)
    Especially, I think we're not at GA level, because I have already two
    concerns preventing me from seeing the required level of quality:

    - Today I filed WW-1711, which turned out to be a ducplicate of two
    already filed issues (and should now be fixed in SVN for 2.0.6). The
    issue is about select tag which does not show the already selected model
    value when form renders, if the model value is of any other type than
    String. I think this is something you can see as minor issue for a Beta
    release, but not for GA (I stumbled over it while doing a three view
    technology demo)
    - Regarding the discussion of doubled ServletRequestAware interface in
    api and core module, I can very much live with the general opinion that
    we don't need a GA quality api module so far - but I would like to see
    all classes and interfaces which users will most likely refer to to have
    proper naming and reside in proper package. IMO, at least for
    ServletRequestAware (maybe for others too) this is probably not the case
    - sooner or later org.apache.struts2.interceptor.ServletRequestAware has
    to be moved to org.apache.struts2.servlet.ServletRequestAware, if in a
    separated api module or simply in core module. But if we throw out a GA
    now, we commit on a certain api stability which I doubt we can guarantee
    in nearest future. So, before going GA, I'm +1 for reviewing most
    commonly used interfaces and classes to be at least stable regarding
    package naming and base contracts. If we would agree on this need, I
    would of course volunteer to participate in reviewing.

    - Rene

    Ted Husted schrieb:
    The Struts 2.0.5 test build is now available.

    Release notes:
    * http://struts.apache.org/2.x/docs/release-notes-205.html

    Distribution:
    * http://people.apache.org/builds/struts/2.0.5/

    Maven 2 staging repository:
    * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/

    If you have had a chance to review the test build, please respond with
    a vote on its quality:

    [ ] Leave at test build
    [ ] Alpha
    [ ] Beta
    [ ] General Availability (GA)

    Everyone who has tested the build is invited to vote. Votes by PMC
    members are considered binding. A vote passes if there are at least
    three binding +1s and more +1s than -1s.

    Please remember that a *binding* +1 for GA implies that you intend to
    support the release by applying patches and responding to posts to the
    user and dev lists.

    The vote will remain open for at least 72 hours, longer upon request.

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Ted Husted at Feb 7, 2007 at 12:50 am

    On 2/6/07, Rene Gielen wrote:
    But if we throw out a GA now,
    we commit on a certain api stability which I doubt we can guarantee
    in nearest future.
    The "new API" is clearly marked experimental, and so I don't feel that
    we would be committing to anything. Worse case, we could roll to
    2.1.x, and move on.

    But, as to the new API, I believe the current feeling is that we
    should send it to the sandbox for now, and revisit the issue after
    Guice stabilizes. Someone just needs to detangle it from the
    ObjectFactory first.

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • David H. DeWolf at Feb 7, 2007 at 12:34 pm

    Ted Husted wrote:

    [ ] Leave at test build
    [ ] Alpha
    [ ] Beta
    [ X ] General Availability (GA)
    +1 GA

    Deployed and tested into our qa environment without any glitches.
    Moving to production soon without any reservations.

    >

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Ted Husted at Feb 7, 2007 at 12:42 pm

    On 2/5/07, Ted Husted wrote:
    [ ] Leave at test build
    [ ] Alpha
    [x] Beta
    [ ] General Availability (GA)
    We've had a lot of comments on the prior test builds, and so I do have
    confidence in the bits. But, I'd still like to have a brief ten-day
    beta period, to encourage wider testing and participation by the
    greater community in the release process.

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Martin Cooper at Feb 7, 2007 at 7:47 pm

    On 2/5/07, Ted Husted wrote:
    The Struts 2.0.5 test build is now available.

    Release notes:
    * http://struts.apache.org/2.x/docs/release-notes-205.html

    Distribution:
    * http://people.apache.org/builds/struts/2.0.5/

    Maven 2 staging repository:
    * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/

    If you have had a chance to review the test build, please respond with
    a vote on its quality:

    [ ] Leave at test build
    [ ] Alpha
    [ ] Beta
    [ ] General Availability (GA)

    Everyone who has tested the build is invited to vote. Votes by PMC
    members are considered binding. A vote passes if there are at least
    three binding +1s and more +1s than -1s.

    Please remember that a *binding* +1 for GA implies that you intend to
    support the release by applying patches and responding to posts to the
    user and dev lists.

    No, it implies no such thing. A binding +1 for GA is a statement that you
    believe that the code is of a quality commensurate with a release to a
    general audience. It is not an implication of personal support or anything
    else. Further, a determination of GA status is up to each PMC member to
    make, and does not require anything in the way of deployment, production
    usage, or anything else of the sort.

    --
    Martin Cooper


    The vote will remain open for at least 72 hours, longer upon request.
    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Ted Husted at Feb 7, 2007 at 9:18 pm

    On 2/7/07, Martin Cooper wrote:
    No, it implies no such thing. A binding +1 for GA is a statement that you
    believe that the code is of a quality commensurate with a release to a
    general audience. It is not an implication of personal support or anything
    else. Further, a determination of GA status is up to each PMC member to
    make, and does not require anything in the way of deployment, production
    usage, or anything else of the sort.
    From our bylaws:
    "The act of voting carries certain obligations. Voters are not only
    stating their opinion, they are also agreeing to help do the work."

    * http://struts.apache.org/dev/bylaws.html

    I would suggest that the work of a GA release includes helping by
    applying patches and answering posts to the user list.

    Our language is taken from the HTTPD guidelines

    * http://httpd.apache.org/dev/guidelines.html

    which also mentions that "On some issues, this vote is only binding if
    the voter has tested the action on their own system(s)." I would
    suggest that in terms of a vote on a GA release, this means that the
    voter is using the bits in production ("eating our own dog food").

    The need for production testing is also mentioned in the HTTPD release
    guidelines.

    * http://httpd.apache.org/dev/release.html

    under "How can an RM be confident in a release?"

    Of course, it also says "each committer is free to come up with their
    own personal voting guidelines", which is why I used the word
    "implies" rather than a more concrete term like "means".

    If a PMC member is voting +1 on a GA, but hasn't used the release in
    production, or does not intend to support the release afterwards,
    personally, I'd like to know that, so that other volunteers are not
    left "holding the bag".

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Martin Cooper at Feb 7, 2007 at 9:43 pm

    On 2/7/07, Ted Husted wrote:
    On 2/7/07, Martin Cooper wrote:
    No, it implies no such thing. A binding +1 for GA is a statement that you
    believe that the code is of a quality commensurate with a release to a
    general audience. It is not an implication of personal support or anything
    else. Further, a determination of GA status is up to each PMC member to
    make, and does not require anything in the way of deployment, production
    usage, or anything else of the sort.
    From our bylaws:

    "The act of voting carries certain obligations. Voters are not only
    stating their opinion, they are also agreeing to help do the work."

    * http://struts.apache.org/dev/bylaws.html

    I would suggest that the work of a GA release includes helping by
    applying patches and answering posts to the user list.

    In earlier Struts releases, we have taken this to mean that someone is
    willing to help produce the release. I don't see how that morphs into a
    commitment to support the release after the fact.

    Our language is taken from the HTTPD guidelines
    * http://httpd.apache.org/dev/guidelines.html

    which also mentions that "On some issues, this vote is only binding if
    the voter has tested the action on their own system(s)." I would
    suggest that in terms of a vote on a GA release, this means that the
    voter is using the bits in production ("eating our own dog food").

    Yes, well _suggesting_ that is fine; making it a requirement is not.

    The need for production testing is also mentioned in the HTTPD release
    guidelines.

    * http://httpd.apache.org/dev/release.html

    under "How can an RM be confident in a release?"

    Of course, it also says "each committer is free to come up with their
    own personal voting guidelines", which is why I used the word
    "implies" rather than a more concrete term like "means".


    If a PMC member is voting +1 on a GA, but hasn't used the release in
    production, or does not intend to support the release afterwards,
    personally, I'd like to know that, so that other volunteers are not
    left "holding the bag".

    Not everyone is in a position to use a release "in production" the way you
    suggest, and certainly not in the timeframe required for a release vote.
    What if I'm developing a product that won't ship for another year? Are you
    saying that I can't vote GA, even if I think it's a rock solid release, just
    because I can't ship a product built on it for another 12 months? I hope
    not.

    And what changed, and when, from the Struts 1 model? Back when I was the
    release manager for Struts 1.x, there were no statements about being "in
    production" before voting, and I certainly voted +1 for several releases on
    the basis of comprehensive testing that I'd performed, not whether I had it
    in production or not. Given that I was working on long-term products at the
    time (as I am now), there's no way I could have had it in production in time
    fr the vote anyway.

    --
    Martin Cooper


    -Ted.
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Wendy Smoak at Feb 9, 2007 at 2:28 am

    On 2/7/07, Martin Cooper wrote:
    On 2/7/07, Ted Husted wrote:

    * http://httpd.apache.org/dev/guidelines.html

    which also mentions that "On some issues, this vote is only binding if
    the voter has tested the action on their own system(s)." I would
    suggest that in terms of a vote on a GA release, this means that the
    voter is using the bits in production ("eating our own dog food").
    Yes, well _suggesting_ that is fine; making it a requirement is not.
    FWIW, the language in recent vote threads makes me less likely to take
    the time to test, since I don't have Struts apps in production
    anymore. I think we all have different roles to play, and that a vote
    based on exercising the example apps and examining the distribution
    for adherence to ASF release guidelines is just as valuable as a vote
    saying that it's working in a production system.

    --
    Wendy

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Ted Husted at Feb 9, 2007 at 4:18 am

    On 2/7/07, Martin Cooper wrote:
    which also mentions that "On some issues, this vote is only binding if
    the voter has tested the action on their own system(s)." I would
    suggest that in terms of a vote on a GA release, this means that the
    voter is using the bits in production ("eating our own dog food").
    Yes, well _suggesting_ that is fine; making it a requirement is not.
    It wasn't my intention to make anything a requirement. Hey, since when
    does anyone listen to me? :)

    My main concern is that the people who are casting binding votes are
    also agreeing to support the release. I believe that an essential
    component of a "quality commensurate with a release to a general
    audience" are people who will available to support the release after
    it is marked GA.

    If a PMC member has essentially gone "emeritus" in terms of a
    particular release, then I would suggest that is better for that
    individual to abstain. Despite its name, the PMC is not a political
    body, but a working group, and we need to know which people in the
    group are ready, willing, and able to do the work.

    My suggestion would be that we adopt the habit of reminding people
    that "A binding vote not only states an opinion, but means that the
    voter is agreeing to help do the work."

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Rainer Hermanns at Feb 8, 2007 at 11:41 am

    [ ] Leave at test build
    [ ] Alpha
    [ X ] Beta
    [ ] General Availability (GA)
    cheers,
    Rainer

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Ted Husted at Feb 9, 2007 at 3:13 am
    OK, after thee days, we have

    GA - Binding
    +1 Patrick Lightbody

    Beta - Binding
    +1 Rene Gielen
    +1 Alexandru Popescu
    +1 Ted Husted
    +1 Rainer Hermanns

    GA - Non Binding
    +1 Matt Raible
    +1 Philip Luppens
    +1 David H. DeWolf

    I've submitted the 2.0.5 release for mirroring, so we can update the
    releases page and make a public announcement in 24 hours.

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Tom Schneider at Feb 11, 2007 at 4:35 am
    Umm, it looks like the spring plugin jar isn't included. Someone on
    #struts mentioned this and I confirmed it by downloading
    struts-2.0.5-all.zip from the website and it's not in the lib
    directory. (All the other plugins are there) Am I crazy or is it
    really missing?
    Tom

    Ted Husted wrote:
    The Struts 2.0.5 test build is now available.

    Release notes:
    * http://struts.apache.org/2.x/docs/release-notes-205.html

    Distribution:
    * http://people.apache.org/builds/struts/2.0.5/

    Maven 2 staging repository:
    * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/

    If you have had a chance to review the test build, please respond with
    a vote on its quality:

    [ ] Leave at test build
    [ ] Alpha
    [ ] Beta
    [ ] General Availability (GA)

    Everyone who has tested the build is invited to vote. Votes by PMC
    members are considered binding. A vote passes if there are at least
    three binding +1s and more +1s than -1s.

    Please remember that a *binding* +1 for GA implies that you intend to
    support the release by applying patches and responding to posts to the
    user and dev lists.

    The vote will remain open for at least 72 hours, longer upon request.

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Dave Newton at Feb 11, 2007 at 4:41 am

    --- Tom Schneider wrote:
    Am I crazy or is it really missing?
    It wasn't in mine; I copied it from showcase again.

    Dave




    ____________________________________________________________________________________
    Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Wendy Smoak at Feb 11, 2007 at 4:47 am

    On 2/10/07, Tom Schneider wrote:
    Umm, it looks like the spring plugin jar isn't included. Someone on
    #struts mentioned this and I confirmed it by downloading
    struts-2.0.5-all.zip from the website and it's not in the lib
    directory. (All the other plugins are there) Am I crazy or is it
    really missing?
    If you've confirmed it, please open an issue against 2.0.5. The file
    is probably missing from the assembly descriptor.

    --
    Wendy

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Ted Husted at Feb 11, 2007 at 12:59 pm

    On 2/10/07, Wendy Smoak wrote:
    On 2/10/07, Tom Schneider wrote:
    Umm, it looks like the spring plugin jar isn't included. Someone on
    #struts mentioned this and I confirmed it by downloading
    struts-2.0.5-all.zip from the website and it's not in the lib
    directory. (All the other plugins are there) Am I crazy or is it
    really missing?
    If you've confirmed it, please open an issue against 2.0.5. The file
    is probably missing from the assembly descriptor.

    --Wendy
    Yes, both the Spring Plugin and Codebehind Plugin are missing from the
    assembly POM.

    Do we just want to

    (1) note this as a known issue,
    (2) branch on 2.0.5 and issue a 2.0.5.1 version of the lib and all
    distributions.
    (3) issue 2.0.6 from the 2.0.x branch.

    I could do any of these things today. If we do (3), I would first drop
    and recreate the 2.0.x tag from the 2.0.5 tag, so as to skip over the
    changes that broke the HEAD after 2.0.5 was tag. (Last time I branch
    the HEAD rather than a tag!)

    Another build issue is that the TLD is being rewritten during the
    assembly, I guess to reflect changes to the annotations. Should we be
    running an assembly before the tag first, to look for TLD updates, and
    checking those in, before continuing with the rest of the tag and
    roll?


    Index: struts-tags.tld
    ===================================================================
    --- struts-tags.tld (revision 503710)
    +++ struts-tags.tld (working copy)
    @@ -2762,7 +2762,7 @@
    <name>doubleListKey</name>
    <required>false</required>
    <rtexprvalue>true</rtexprvalue>
    - <description><![CDATA[Set the list key of the second
    attribute]]></description>
    + <description><![CDATA[The key expression to use for second
    list]]></description>
    </attribute>
    <attribute>
    <name>doubleListValue</name>
    @@ -5270,7 +5270,7 @@
    <name>doubleListKey</name>
    <required>false</required>
    <rtexprvalue>true</rtexprvalue>
    - <description><![CDATA[Set the list key of the second
    attribute]]></description>
    + <description><![CDATA[The key expression to use for second
    list]]></description>
    </attribute>
    <attribute>
    <name>doubleListValue</name>

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Tom Schneider at Feb 11, 2007 at 2:45 pm
    I vote for creation of a 2.0.x branch. There's several issues from
    webwork that haven't been applied to the 2.0.x series and I'm sure there
    will be more that will need to be carried forward.
    Tom

    Ted Husted wrote:
    Yes, both the Spring Plugin and Codebehind Plugin are missing from the
    assembly POM.

    Do we just want to

    (1) note this as a known issue,
    (2) branch on 2.0.5 and issue a 2.0.5.1 version of the lib and all
    distributions.
    (3) issue 2.0.6 from the 2.0.x branch.

    I could do any of these things today. If we do (3), I would first drop
    and recreate the 2.0.x tag from the 2.0.5 tag, so as to skip over the
    changes that broke the HEAD after 2.0.5 was tag. (Last time I branch
    the HEAD rather than a tag!)

    Another build issue is that the TLD is being rewritten during the
    assembly, I guess to reflect changes to the annotations. Should we be
    running an assembly before the tag first, to look for TLD updates, and
    checking those in, before continuing with the rest of the tag and
    roll?


    Index: struts-tags.tld
    ===================================================================
    --- struts-tags.tld (revision 503710)
    +++ struts-tags.tld (working copy)
    @@ -2762,7 +2762,7 @@
    <name>doubleListKey</name>
    <required>false</required>
    <rtexprvalue>true</rtexprvalue>
    - <description><![CDATA[Set the list key of the second
    attribute]]></description>
    + <description><![CDATA[The key expression to use for second
    list]]></description>
    </attribute>
    <attribute>
    <name>doubleListValue</name>
    @@ -5270,7 +5270,7 @@
    <name>doubleListKey</name>
    <required>false</required>
    <rtexprvalue>true</rtexprvalue>
    - <description><![CDATA[Set the list key of the second
    attribute]]></description>
    + <description><![CDATA[The key expression to use for second
    list]]></description>
    </attribute>
    <attribute>
    <name>doubleListValue</name>

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Wendy Smoak at Feb 11, 2007 at 2:59 pm

    On 2/11/07, Ted Husted wrote:

    Yes, both the Spring Plugin and Codebehind Plugin are missing from the
    assembly POM.

    Do we just want to

    (1) note this as a known issue,
    (2) branch on 2.0.5 and issue a 2.0.5.1 version of the lib and all
    distributions.
    (3) issue 2.0.6 from the 2.0.x branch.

    I could do any of these things today. If we do (3), I would first drop
    and recreate the 2.0.x tag from the 2.0.5 tag, so as to skip over the
    changes that broke the HEAD after 2.0.5 was tag. (Last time I branch
    the HEAD rather than a tag!)
    My vote goes to (3) including re-branching 2.0.x from the 2.0.5 tag.
    Another build issue is that the TLD is being rewritten during the
    assembly, I guess to reflect changes to the annotations. Should we be
    running an assembly before the tag first, to look for TLD updates, and
    checking those in, before continuing with the rest of the tag and
    roll?
    I'm not familiar enough with this to comment. Does this mean we're
    checking a generated file into svn?

    --
    Wendy

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Ted Husted at Feb 11, 2007 at 3:39 pm

    On 2/11/07, Wendy Smoak wrote:
    I'm not familiar enough with this to comment. Does this mean we're
    checking a generated file into svn?
    My understanding is the annotations are generating the TLD. We checked
    the TLD when we were having problems with the generation, but I don't
    know if we want to keep it checked in or not.

    We also checkin the HTML docs for the tags, at

    * struts2/core/src/site/resources/tags

    I believe for the benefit of the snippet macro.

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org
  • Musachy Barroso at Feb 11, 2007 at 4:21 pm
    The TLD is always generated. It was removed at some point, but when we had
    the problem with the annotations, it was added back until the problem would
    be fixed, so it can be removed now.

    musachy
    On 2/11/07, Ted Husted wrote:
    On 2/11/07, Wendy Smoak wrote:
    I'm not familiar enough with this to comment. Does this mean we're
    checking a generated file into svn?
    My understanding is the annotations are generating the TLD. We checked
    the TLD when we were having problems with the generation, but I don't
    know if we want to keep it checked in or not.

    We also checkin the HTML docs for the tags, at

    * struts2/core/src/site/resources/tags

    I believe for the benefit of the snippet macro.

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org

    --
    "Hey you! Would you help me to carry the stone?" Pink Floyd
  • Psaumets at Feb 11, 2007 at 5:01 am
    Haha! I couldve confirmed this a coupple days ago when I updated. I just assumed it was a missed jar. Ejnded up just grabbing it from the showcase example. Anyways it def should be included in thr full lib.
    Sent from my BlackBerry device on the Rogers Wireless Network

    -----Original Message-----
    From: Tom Schneider <schneidh@gmail.com>
    Date: Sat, 10 Feb 2007 22:37:08
    To:Struts Developers List <dev@struts.apache.org>
    Subject: Re: [VOTE] Struts 2.0.5 Quality

    Umm, it looks like the spring plugin jar isn't included. Someone on
    #struts mentioned this and I confirmed it by downloading
    struts-2.0.5-all.zip from the website and it's not in the lib
    directory. (All the other plugins are there) Am I crazy or is it
    really missing?
    Tom

    Ted Husted wrote:
    The Struts 2.0.5 test build is now available.

    Release notes:
    * http://struts.apache.org/2.x/docs/release-notes-205.html

    Distribution:
    * http://people.apache.org/builds/struts/2.0.5/

    Maven 2 staging repository:
    * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/

    If you have had a chance to review the test build, please respond with
    a vote on its quality:

    [ ] Leave at test build
    [ ] Alpha
    [ ] Beta
    [ ] General Availability (GA)

    Everyone who has tested the build is invited to vote. Votes by PMC
    members are considered binding. A vote passes if there are at least
    three binding +1s and more +1s than -1s.

    Please remember that a *binding* +1 for GA implies that you intend to
    support the release by applying patches and responding to posts to the
    user and dev lists.

    The vote will remain open for at least 72 hours, longer upon request.

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
    For additional commands, e-mail: dev-help@struts.apache.org

Related Discussions