[Struts-dev] [VOTE] Struts 2.0.5 Quality

Tested with AppFuse 2:

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

Non-binding.

Matt

+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

+0 for GA. I have some testing code that looks good, but no production
code that has been converted.

/Ian

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

Beta is also an option :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

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:

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

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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

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:

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

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:

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

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

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

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:

True. And if we had a stable release of XWork 2 in September, I
believe that we would have marked 2.0.1 GA.
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

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

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:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

+1
I totally agree with this.

Full +1 for this.

./alex
--
.w( the_mindstorm )p.
---------------------------------------------------------------------
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

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

I fully agree with Ted's explanation of vote meanings so
./alex
--
.w( the_mindstorm )p.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.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.
Cheers,

Phil

I'm going to do more testing this week, but I think (fear?) I have a
first opinion so far:
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:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

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

+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

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

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.

"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

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

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

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


If a PMC member is voting +1 on a GA, but hasn't used the release in

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.

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.

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

cheers,
Rainer

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

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

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:

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

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

If you've confirmed it, please open an issue against 2.0.5. The file
is probably missing from the assembly descriptor.

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

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:

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

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

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

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:

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