On 5/16/06, Ted Husted [EMAIL PROTECTED] wrote:
I won't cast a quality vote on anything but a tagged and rolled,
downloadable distribution. Many of the problems we've had in the past
(not just this time, but with other series too) appear in the final
product and are not evident in a checkout.
On 5/16/06, Don Brown [EMAIL PROTECTED] wrote:
I think the solution is to:
1. Make betas publicly available and widely known like our 1.1 betas were
+1. Based on this and other comments, I'd like to add the following
to the release guidelines [1]:
* Versions with significant changes,
On 5/17/06, Wendy Smoak [EMAIL PROTECTED] wrote:
I agree with Ted and Paul that we should only vote on the actual
signed distribution that's going to be uploaded. It's easy to imagine
accidentally introduce a problem when you're building the final
distribution. I wouldn't be comfortable
On 5/17/06, Don Brown [EMAIL PROTECTED] wrote:
Ok, so if you don't think this is the answer to the backwards release
then test problem, what is?
I don't know. Earlier 1.x releases had the benefit of the entire team
focused on them, and more people using nightly builds. That's no
longer the
On 5/17/06, Don Brown [EMAIL PROTECTED] wrote:
I'd guess 90+% of other open source projects seem to do just fine
doing all the testing and voting before the release.
I'm not aware of any project, open or closed source, that only issues
stable or GA releases without issuing any type of beta or
On 5/16/06, Ted Husted [EMAIL PROTECTED] wrote:
On 5/16/06, Don Brown [EMAIL PROTECTED] wrote:
I think the solution is to:
1. Make betas publicly available and widely known like our 1.1 betas
were
+1
I think the notion that we can't announce and mirrors Betas is a
misunderstanding. We can
On 5/17/06, Craig McClanahan [EMAIL PROTECTED] wrote:
Announce and mirror are two different things. IIRC, Apache's general
guidelines on mirror are GA releases only (although we've probably been
among the folks that bypassed that policy on occasion).
The FAQ suggest that all releases be
At 1:07 PM -0500 5/16/06, Joe Germuska wrote:
I've uncovered a couple of things in porting an old Struts 1.1
application to 1.3; I know they probably need to go in Jira, but I
wanted to get a little discussion about them before filing them.
Actually, now I think i'll send them separately with
At 1:07 PM -0500 5/16/06, Joe Germuska wrote:
I've uncovered a couple of things in porting an old Struts 1.1
application to 1.3; I know they probably need to go in Jira, but I
wanted to get a little discussion about them before filing them.
Actually, now I think i'll send them separately with
What I dislike is spending untold personal hours fixing all known
issues and putting out a release, only to have it continually shot
down, not available to anyone. Specifically:
1. Our release plan states we only make GA's available on the mirrors
and from the download page, so anything less is
On 5/16/06, Don Brown [EMAIL PROTECTED] wrote:
I think the solution is to:
1. Make betas publicly available and widely known like our 1.1 betas were
+1
I think the notion that we can't announce and mirrors Betas is a
misunderstanding. We can mirror an announce *any* release, even an
Alpha.
I am +2 with Don's idea. Quite frankly, my favorite Apache projects
besides Struts are Tapestry and Tomcat, and those PUT OUT BETA versions
on their website. The versions are specifically listed as beta, and then they
change the website to list it as GA if a vote changes it.
-- Paul
--- Don
I am also -1 because on #2 that's not how I understand the
voting process to work. It's cut a version, publish it out as
beta for developers to use, vote later on it. I model my thoughts
after what I've seen on Tomcat.
-- Paul
--- Ted Husted [EMAIL PROTECTED] wrote:
On 5/16/06, Don Brown
Don,
Then, once the release is out, people nitpick through it finding
issues to shoot it down (and yes, a beta is as good as a killed
release because it doesn't get out to the users in an public,
accessible location).
I must be one of the folk guilty of nit-picking :) But honestly,
I
On 5/14/06, Don Brown [EMAIL PROTECTED] wrote:
If, in six months with 100% dedicated committers willing to
do whatever it takes and a codebase that is stable and proven, we can't
push out a GA release, we have a serious problem.
First, six months of effort would be a record. Typically, the
On 5/14/06, Don Brown [EMAIL PROTECTED] wrote:
yes, a beta is as good as a killed release because it doesn't get out to
the users in an public, accessible location).
Ummm, we can submit a Beta for general circulation and mirroring.
Right now, today, we're doing that with the Shale *Alpha*.
*
On 5/14/06, Ted Husted [EMAIL PROTECTED] wrote:
If it helps, I'd say we could we could even announce the next distribution as
* Stuts Action 1.3.5 Beta (release candidate).
(Given the votes, of course.)
I think the only thing that's broken is the notion that a Beta is not
a Release
Wendy, the only reason I bring this up (and the only reason),
is because I believe the Tiles DTD that has plagued 1.3.4 is
a symptom of the decision.
Listen to this logic: By making branding Tiles a 1.3.x version,
we are directly tying the product to struts. That implies it
is only for Struts,
On 5/14/06, Paul Benedict [EMAIL PROTECTED] wrote:
Listen to this logic: By making branding Tiles a 1.3.x version,
we are directly tying the product to struts. That implies it
is only for Struts, and that's not true.
Struts Tiles *is* tied directly to Struts Action -- look at the
dependency
Wendy, +1 on picking apart my argument :)
Thanks for clearing things up for me; I apologize for missing
the obvious fact that this isn't Standalone Tiles. I got lost
in my philosophy! Thanks again :)
--- Wendy Smoak [EMAIL PROTECTED] wrote:
On 5/14/06, Paul Benedict [EMAIL PROTECTED] wrote:
On 5/14/06, Wendy Smoak [EMAIL PROTECTED] wrote:
I'd rather not re-introduce the term release candidate at this
point, especially not in combination with 'Beta'. Under our current
guidelines, a Beta *is* a release.
And, so is an Alpha. And we can distribute any release - Alpha, Beta,
or GA --
Unless I'm mistaken, the votes I've always seen come up have three
choices: mark a release alpha, beta or GA. This would seem to be the
cause of the problem with the process to me because it in effect
allows the process to be short circuited, i.e., a newly-rolled release
could be marked GA
On 5/14/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Each release can be distributed as far and wide as you want, and in fact
should be, to get as many people testing as possible.
Yes. The reason we stopped putting qualifiers like beta and rc in
the distribution names, was so we could start
On 5/14/06, Wendy Smoak [EMAIL PROTECTED] wrote:
And yes, this means that once a Struts Action 1.3 release is voted GA,
that DTD, along with all the others, the TLDs and the public API, is
set.
Oh, we've managed to make significant changes to the public APIs over
the years. Most often, it's
On 5/11/06, Don Brown [EMAIL PROTECTED] wrote:
Niall Pemberton wrote:
To summarise then my vote is beta because I believe I think we're
introducing an uncessaey PITA for users upgrading and it will increase
questions on the user list and put additional load on the Apache
Servers.
I
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote:
Once you have had a chance to review this test build, please respond
with a vote on its quality:
[ ] Alpha
[X] Beta
[ ] General Availability (GA)
Sorry for the late response - I've been at The Ajax Experience conference
for the last couple of
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote:
[ ] Alpha
[X] Beta
[ ] General Availability (GA)
I would prefer that we resolve the DTD issue before marking a
distribution ready for primetime.
-Ted.
-
To unsubscribe,
I know it is against our best practices, but can you just fix
1.3.4 with the correct DTD and then retag it? Do we need a new
version (1.3.5) just for this? I am okay either which way. -- Paul
--- Martin Cooper [EMAIL PROTECTED] wrote:
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote:
Once
On 5/13/06, Paul Benedict [EMAIL PROTECTED] wrote:
I know it is against our best practices, but can you just fix
1.3.4 with the correct DTD and then retag it?
No. If we did that, (a) anyone who had run a Maven build against the
1.3.4that's up there now would still be using the old
1.3.4,
On 5/13/06, Martin Cooper [EMAIL PROTECTED] wrote:
Do we need a new
version (1.3.5) just for this?
Unfortunately, yes. It's the only reliable way.
It also would not be any more work that hacking the 1.3.4 build.
We'd have to do all the same things either way. Once the DTD issue is
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote:
The Struts Action Framework 1.3.4 Test Build is available to evaluate
for release quality.
The release plan is available on the wiki:
http://wiki.apache.org/struts/StrutsActionRelease134
The test build, including checksums and signatures, has
On 5/13/06, Ted Husted [EMAIL PROTECTED] wrote:
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote:
[ ] Alpha
[X] Beta
[ ] General Availability (GA)
I would prefer that we resolve the DTD issue before marking a
distribution ready for primetime.
I agree ... and vote for beta as well.
But
I recommend we withdrawl the availablity of 1.3.4 from
the download servers. Because this problem affects infrastructure,
I do not believe it should remain as a version to be downloaded.
Sometimes a distribution should just be killed off completely.
--- Wendy Smoak [EMAIL PROTECTED] wrote:
On
I am uneasy with the way that Struts Scripting and Struts Tiles
is being released under the 1.3.4 moniker. It doesn't make any
sense to me. The reason I say this is because they are, in a kind
of way, a different product.
Tiles is 1.1 despite the new 1.3.4 name. It is not in its 3rd
version,
On 5/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 5/13/06, Ted Husted [EMAIL PROTECTED] wrote:
I would prefer that we resolve the DTD issue before marking a
distribution ready for primetime.
I agree ... and vote for beta as well.
But we should spend some more time testing to see if
On 5/13/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 5/13/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 5/13/06, Ted Husted [EMAIL PROTECTED] wrote:
I would prefer that we resolve the DTD issue before marking a
distribution ready for primetime.
I agree ... and vote for beta as well.
Craig McClanahan wrote:
However, I would be unhappy with
all of us other committers if we stopped testing 1.3.4 at all, until
1.3.5became available, and we surface yet another two line change next
week.
This is exactly why I think this release process, or least least the
Struts PMC
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote:
The Struts Action Framework 1.3.4 Test Build is available to evaluate
for release quality.
...
The test build, including checksums and signatures, has been deployed to:
http://svn.apache.org/dist/struts/action/v1.3.4
Late tonight, the vote
On 5/10/06, Don Brown [EMAIL PROTECTED] wrote:
For the next significant release, I'm fine with waiting the extra week.
As mentioned elsewhere, quality votes are not meant to be a permanent
judgment. If problems are found, we can recast our votes and
re-qualify the quality of the release.
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote:
Niall, does Monday give you enough time? Calling the vote immediately
was intended to encourage testing and evaluation, not to lock people
out of the process by rushing it through.
As mentioned elsewhere, a release is a process that is never
On 5/10/06, Don Brown [EMAIL PROTECTED] wrote:
We can always recall a release
We can reclassify the quality of a release, but once it hits the
mirrors, it hits the mirrors, so we can't recall it per se.
or throw out a new one if a major issue
has been found,
We can roll another 1.x
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote:
I remember being involved -- it had to do with the version numbers not
matching. It seems odd to use Struts Tiles 1.3 with a version 1.1
DTD.
+1
There's a general expectation that the DTD release number match the
product release number. If we
On May 10, 2006, at 10:02 PM, Wendy Smoak wrote:
On 5/10/06, Niall Pemberton [EMAIL PROTECTED] wrote:
I missed the discussion where the 1.3 dtd was added - seems like its
actually identical to the 1.1 dtd - which IMO serves no purpose. I
would rather it was removed.
I remember being
On 5/11/06, Ted Husted [EMAIL PROTECTED] wrote:
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote:
Niall, does Monday give you enough time? Calling the vote immediately
was intended to encourage testing and evaluation, not to lock people
out of the process by rushing it through.
As mentioned
On 5/11/06, Ted Husted [EMAIL PROTECTED] wrote:
On 5/10/06, Wendy Smoak [EMAIL PROTECTED] wrote:
I remember being involved -- it had to do with the version numbers not
matching. It seems odd to use Struts Tiles 1.3 with a version 1.1
DTD.
+1
There's a general expectation that the DTD
Niall Pemberton wrote:
To summarise then my vote is beta because I believe I think we're
introducing an uncessaey PITA for users upgrading and it will increase
questions on the user list and put additional load on the Apache
Servers.
I absolutely disagree. To be GA quality, it doesn't have to
On 5/11/06, Don Brown [EMAIL PROTECTED] wrote:
Furthermore, this is such a small issue to
pull back an entire release is way overkill.
A release can't be vetoed. As long as there are more binding GAs than
binding something-elses, it's GA. We each have earned the right to
express our own
On 5/11/06, Don Brown [EMAIL PROTECTED] wrote:
Niall Pemberton wrote:
To summarise then my vote is beta because I believe I think we're
introducing an uncessaey PITA for users upgrading and it will increase
questions on the user list and put additional load on the Apache
Servers.
I
On 5/11/06, Ted Husted [EMAIL PROTECTED] wrote:
On 5/11/06, Don Brown [EMAIL PROTECTED] wrote:
Furthermore, this is such a small issue to
pull back an entire release is way overkill.
A release can't be vetoed. As long as there are more binding GAs than
binding something-elses, it's GA. We
I have taken some time to check out the 1.3.4 version today -
upgrading my webapp to this version (was on 1.2.9) and the only other
issue(s) I came up with is that we used to distribute things like the
validator-rules.xml config and taglib tlds in the lib directory. I
releaize that these are now
Joe Germuska wrote:
I have taken some time to check out the 1.3.4 version today -
upgrading my webapp to this version (was on 1.2.9) and the only other
issue(s) I came up with is that we used to distribute things like the
validator-rules.xml config and taglib tlds in the lib directory. I
On 5/11/06, Niall Pemberton [EMAIL PROTECTED] wrote:
I have taken some time to check out the 1.3.4 version today -
upgrading my webapp to this version (was on 1.2.9) and the only other
issue(s) I came up with is that we used to distribute things like the
validator-rules.xml config and taglib
On 5/11/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 5/11/06, Niall Pemberton [EMAIL PROTECTED] wrote:
I have taken some time to check out the 1.3.4 version today -
upgrading my webapp to this version (was on 1.2.9) and the only other
issue(s) I came up with is that we used to distribute
On 5/11/06, Wendy Smoak [EMAIL PROTECTED] wrote:
Since we now require Servlet 2.3, there's little reason to configure
tlds in web.xml, and there's no reason to keep a copy of
validator-rules.xml in WEB-INF when it can be loaded from
struts-core.jar.
We can include them in 'lib' in the next
On 5/11/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 5/11/06, Niall Pemberton [EMAIL PROTECTED] wrote:
I have taken some time to check out the 1.3.4 version today -
upgrading my webapp to this version (was on 1.2.9) and the only other
issue(s) I came up with is that we used to distribute
At 10:50 AM -0700 5/11/06, Michael Jouravlev wrote:
I think it is much cleaner to have DTDs and other default XML files in
the JAR, but sometimes it might not work.
The hosting that I use for the samples, uses Tomcat 4.x, which
supposedly should support SRV 2.3 and therefore it should be able
On 5/11/06, Joe Germuska [EMAIL PROTECTED] wrote:
At 10:50 AM -0700 5/11/06, Michael Jouravlev wrote:
I think it is much cleaner to have DTDs and other default XML files in
the JAR, but sometimes it might not work.
The hosting that I use for the samples, uses Tomcat 4.x, which
supposedly
On 5/11/06, Craig McClanahan [EMAIL PROTECTED] wrote:
I think we should include the DTDs in some convenient place like lib in
the distro in *addition* to the previous comments on recommended
configuration practices. There's lots of documentation about valid options
in the DTD documents
On 5/11/06, Niall Pemberton [EMAIL PROTECTED] wrote:
No problem, its a minor contribution compared to your efforts to get a
1.3.x version out - thanks for that. Apologies if you think I'm being
a PITA.
I don't think that at all. We may differ on whether a particular
issue is reason enough to
The Struts Action Framework 1.3.4 Test Build is available to evaluate
for release quality.
The release plan is available on the wiki:
http://wiki.apache.org/struts/StrutsActionRelease134
The test build, including checksums and signatures, has been deployed to:
GA - This looks really good Wendy, thanks again for the hard work!
Don
Wendy Smoak wrote:
The Struts Action Framework 1.3.4 Test Build is available to evaluate
for release quality.
The release plan is available on the wiki:
http://wiki.apache.org/struts/StrutsActionRelease134
The test
This seems like the smallest of things, but the distribution includes
struts-core-1.3.4.jar and not struts-action-1.3.4.jar.
I thought we'd decided to change that? The upgrade notes wiki page
refers to struts-action:
http://wiki.apache.org/struts/StrutsUpgradeNotes12to13
Like Wendy, I've
I didn't know we decided to change that, as it has repercussions all throughout
the Maven build. I'm fine with us changing it for the next release, but I
certainly don't think it should stand in the way of this one.
Don
Joe Germuska wrote:
This seems like the smallest of things, but the
On 5/10/06, Joe Germuska [EMAIL PROTECTED] wrote:
This seems like the smallest of things, but the distribution includes
struts-core-1.3.4.jar and not struts-action-1.3.4.jar.
I thought we'd decided to change that? The upgrade notes wiki page
refers to struts-action:
At 11:21 AM -0700 5/10/06, Wendy Smoak wrote:
On 5/10/06, Joe Germuska [EMAIL PROTECTED] wrote:
This seems like the smallest of things, but the distribution includes
struts-core-1.3.4.jar and not struts-action-1.3.4.jar.
I thought we'd decided to change that? The upgrade notes wiki page
On 5/10/06, Joe Germuska [EMAIL PROTECTED] wrote:
At 11:21 AM -0700 5/10/06, Wendy Smoak wrote:
On 5/10/06, Joe Germuska [EMAIL PROTECTED] wrote:
This seems like the smallest of things, but the distribution includes
struts-core-1.3.4.jar and not struts-action-1.3.4.jar.
I thought we'd decided
In the past we've made a new version available for people to check out
for a period of time (my preference is at least a week) before calling
a vote.
I'm against this process of publishing and calling a vote immediately
as I believe it increases the chance of a build with problems being
voted
Normally, I'd agree with you but:
a) This is the latest in a succession of very recent releases so little
has changed (last one was Sunday)
b) Theoretically people test during that week, but in practice few do.
Seems people don't pay attention until a vote is called
We can always recall a
On 5/10/06, Niall Pemberton [EMAIL PROTECTED] wrote:
I missed the discussion where the 1.3 dtd was added - seems like its
actually identical to the 1.1 dtd - which IMO serves no purpose. I
would rather it was removed.
I remember being involved -- it had to do with the version numbers not
69 matches
Mail list logo
