Ted Husted-3 wrote:

The Struts 2.0.5 test build is now available.

Release notes:
*

Distribution:
*

Maven 2 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

I fully agree with Ted's explanation of vote meanings so
[ ] Leave at test build
[ ] Alpha
[ x] Beta
[ ] General Availability (GA)
/alex

2/7/07, Craig McClanahan <craigmcc (AT) apache (DOT) orgwrote:
2/6/07, Don Brown <mrdon (AT) twdata (DOT) orgwrote:

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. 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 SS 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

I'm with Don here - IM, 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:

2/6/07, Don Brown <mrdon (AT) twdata (DOT) orgwrote:
>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/) - Test build against XWork beta 1.

* 2.0.2 (20/) - 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.

IMH, 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.

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 (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

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

2/6/07, Don Brown <mrdon (AT) twdata (DOT) orgwrote:
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 :)

2/6/07, Ian Roughley <ian (AT) fdar (DOT) comwrote:
>+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 (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
>
>
>
>

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
--

2/7/07, Rene Gielen <gielen (AT) it-neering (DOT) netwrote:
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? IM 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:
2/6/07, Don Brown <mrdon (AT) twdata (DOT) orgwrote:
>>
>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-SNAPSHT", but that could
easily become 2.0.0-SNAPSHT 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, IMH I hope that
the
Struts 2 process can improve based on lessons learned from that experience.

Don
--
Craig
--

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
--

2/7/07, Philip Luppens <philip.luppens (AT) gmail (DOT) comwrote:
2/7/07, Rene Gielen <gielen (AT) it-neering (DOT) netwrote:
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? IM 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

2/5/07, Ted Husted <husted (AT) apache (DOT) orgwrote:

The Struts 2.0.5 test build is now available.

Release notes:
*

Distribution:
*

Maven 2 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.

2/7/07, Ted Husted <husted (AT) apache (DOT) orgwrote:

2/7/07, Martin Cooper <martinc (AT) apache (DOT) orgwrote:
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."

*

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.

language is taken from the HTTPD guidelines

*

which also mentions that " 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.

*

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

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.

2/7/07, Martin Cooper <martinc (AT) apache (DOT) orgwrote:
2/7/07, Ted Husted <husted (AT) apache (DOT) orgwrote:

*

which also mentions that " 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.