Hi,
If you didn't notice, INFRA started moving release artifacts from
people.a.o to SvnPubSub and now everything is stored in SVN ;-) Below
is a log from my discussion with INFRA about that. I'm posting it here
to not forget update the Release guideline.
***
L
Just removing it from the build won't do, as the dependencies are
still in assembly/pom.xml. We cannot remove them, because the j4
profile won't work, so I am not sure what to do in this case.
musachy
On Tue, Nov 18, 2008 at 7:55 PM, Musachy Barroso wrote:
> jdk 4 jars generation was removed fro
That's what it was called before(I think it is called j4 in xwork also). But
you have a good point.
musachy
On Sat, Nov 22, 2008 at 5:34 PM, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 18, 2008 at 4:55 PM, Musachy Barroso <[EMAIL PROTECTED]>
> wrote:
>
> > jdk 4 jars generation was rem
On Tue, Nov 18, 2008 at 4:55 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> jdk 4 jars generation was removed from the default build in the
> release_process branch. Just doing 'mvn package -P j4' should be enough to
> generate the jdk 4 jars.
Is there a reason we're calling the profile 'j4'?
jdk 4 jars generation was removed from the default build in the
release_process branch. Just doing 'mvn package -P j4' should be enough to
generate the jdk 4 jars.
//Goodbye j4, you won't be missed :)
musachy
On Mon, Nov 17, 2008 at 1:06 AM, Nils-Helge Garli Hegvik
<[EMAIL PROTECTED]>wrote:
> I
I though this had been decided already, but +1 for dropping it in 2.1
and keeping it in 2.0.x.
Nils-H
On Sun, Nov 16, 2008 at 10:44 PM, Rene Gielen <[EMAIL PROTECTED]> wrote:
> +1 for dropping in 2.1, along with keeping it in 2.0.X
>
> Rainer Hermanns schrieb:
>>
>> I'd vote with +1 for dropping
Since Struts 2.1 does not have a GA release yet, I think it's
acceptable to drop J4 support too. However, make it as easy as
possible to build the J4 support libraries with documentation, and a
*supported* Maven profile.
Paul
On Sun, Nov 16, 2008 at 3:44 PM, Rene Gielen <[EMAIL PROTECTED]> wrote:
+1 for dropping in 2.1, along with keeping it in 2.0.X
Rainer Hermanns schrieb:
I'd vote with +1 for dropping j4-support in Struts 2.1.X
but with -1 for Struts 2.0.X because of known users using
previous 2.0.X backported releases and that are waiting for
another stable GA release for their produ
Just a reminder: Sun isn't the only JDK vendor; I know of a lot of WebFears and
WebIllogics that aren't running 1.5.
I'm still in favor of dropping support, but it's not reasonable to make a
blanket assumption that just because Sun EOL'd 1.4 that (a) scads of people
aren't still running 1.4, an
Sun ended support for Java 1.4 at the end of last month[1], so it would
seem reasonable to drop support for 2.1
Al.
http://java.sun.com/products/archive/eol.policy.html
Rainer Hermanns wrote:
I'd vote with +1 for dropping j4-support in Struts 2.1.X
but with -1 for Struts 2.0.X because of know
I'd vote with +1 for dropping j4-support in Struts 2.1.X
but with -1 for Struts 2.0.X because of known users using
previous 2.0.X backported releases and that are waiting for
another stable GA release for their production systems.
just my 0.02€,
cheers,
Rainer
> Yes, my thoughts were on that dire
Yes, my thoughts were on that direction, drop out direct support and
document what needs to be done, for those that still need it.
musachy
On Sun, Nov 16, 2008 at 12:35 PM, Dave Newton <[EMAIL PROTECTED]> wrote:
> --- On Sun, 11/16/08, Musachy Barroso wrote:
> > I know someone already asked this
--- On Sun, 11/16/08, Musachy Barroso wrote:
> I know someone already asked this but, shouldn't we drop
> the jdk4 support already?
+1, but I'll add a wiki page giving a brief overview of the retro process ("Run
this batch file, loser!")
Dave
---
support
> already?
>
> musachy
>
> On Fri, Nov 14, 2008 at 2:29 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
>
> > With Wendy's help I have modified some poms with the intention of making
> > the release process less painful. I removed most of the profiles
I know someone already asked this but, shouldn't we drop the jdk4 support
already?
musachy
On Fri, Nov 14, 2008 at 2:29 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote:
> With Wendy's help I have modified some poms with the intention of making
> the release process less pain
;> The first thing I notice is that the gpg signing is in the default
>>>> build. If you put it in a profile with an id of 'release' then it
>>>> will be activated automatically during the release process.
>>>>
>>>
&g
ile with an id of 'release' then it
will be activated automatically during the release process.
... except that it won't due to this in pluginManagement:
org.apache.maven.plugins
maven-release-plugin
ts2/branches/release_process
The first thing I notice is that the gpg signing is in the default
build. If you put it in a profile with an id of 'release' then it
will be activated automatically during the release process.
... except that it won't due
MAIL PROTECTED]>
> wrote:
> >
> >>
> https://svn.apache.org/repos/asf/struts/struts2/branches/release_process
> >
> > The first thing I notice is that the gpg signing is in the default
> > build. If you put it in a profile with an id of 'release' then it
&g
that the gpg signing is in the default
> build. If you put it in a profile with an id of 'release' then it
> will be activated automatically during the release process.
... except that it won't due to this in pluginManagement:
org.apache.m
27; then it
will be activated automatically during the release process.
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
With Wendy's help I have modified some poms with the intention of making the
release process less painful. I removed most of the profiles and moved their
configuration to the default build. Changes are on this branch:
https://svn.apache.org/repos/asf/struts/struts2/branches/release_process
2007/9/7, Wendy Smoak <[EMAIL PROTECTED]>:
>
> And just in general, we use the release plugin at Maven, have used it
> at MyFaces, and at work we use the release management feature in
> Continuum (which is based on the same thing).
You forgot to mention Tiles :-)
Antonio
On 9/7/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> I'm nervous since there doesn't seem to be a way to try a "dry run" on
> 2.1.x. Though, since there is no hurry for 2.0.10, if you have time to
> apply the patch to the branch, we might as well try it there first.
Jim pointed out the -DdryRun=tru
2007/9/7, Jim <[EMAIL PROTECTED]>:
>
> Fortunately, you can do a dry run:
>
> mvn release:prepare -DdryRun=true
> After running the dry run, use this to cleanup:
>
> mvn release:clean
>
> See the heading "Do a Dry Run" for the Maven 2 release plugin
> documentation:
>
> http://maven.apache.org/plug
Fortunately, you can do a dry run:
mvn release:prepare -DdryRun=true
After running the dry run, use this to cleanup:
mvn release:clean
See the heading "Do a Dry Run" for the Maven 2 release plugin
documentation:
http://maven.apache.org/plugins/maven-release-plugin/usage.html
On Sep 7, 20
I'm nervous since there doesn't seem to be a way to try a "dry run" on
2.1.x. Though, since there is no hurry for 2.0.10, if you have time to
apply the patch to the branch, we might as well try it there first.
-Ted.
On 9/7/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
> 2007/9/7, Ted Husted <[E
2007/9/7, Ted Husted <[EMAIL PROTECTED]>:
>
> Does step 2 " Tag the release by using the "release:prepare" goal of
> Maven:" actually tag the release in SVN? (How does it know what symbol
> to use?) Or is the word tag being used in another sense?
The sense is right :-) But the "release:prepare"
2007/9/6, Ted Husted <[EMAIL PROTECTED]>:
>
> I just wanted to try a dry-run on 2.1.x first, later tonight (after I
> get some actual work done!).
Just to be complete: the release process won't work until all the snapshot
dependencies are resolved. In particular, there is a
all
> I am in the process of finish configuring the Maven Release plugin for
> Struts 2 (I think that I have finished, but I need to test it to be
> sure).
> In the meantime, I prepared a wiki page that shows how the release
> process will look like:
> http://cwiki.apache.org/confluen
I just wanted to try a dry-run on 2.1.x first, later tonight (after I
get some actual work done!).
-Ted.
On 9/6/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
> 2007/9/6, Ted Husted <[EMAIL PROTECTED]>:
> > Is there any reason why it's labeled for Struts 2.1.x? Could we also
> > try it for 2.0.1
2007/9/6, Ted Husted <[EMAIL PROTECTED]>:
> Is there any reason why it's labeled for Struts 2.1.x? Could we also
> try it for 2.0.10?
Ted, sorry to disturb you, but you did not answer if you want me to
backport the release plugin configuration to 2_0_X.
Antonio
--
On 9/6/07, Paul Benedict <[EMAIL PROTECTED]> wrote:
>
> One thing that is always missing from our release processes is the
> announcements to portal websites. I don't believe the zoom in downloads
> for
> 1.3.8/2.0.8 was a coincidence -- because it was announced very loudly :-)
>
> Make sure you al
Perhaps we should add a section listing the "portal websites" to the
step-by-step
* http://struts.apache.org/2.x/docs/creating-and-signing-a-distribution.html
I believe ApacheNews (an independant entity) feeds from
<[EMAIL PROTECTED]>, which is the cannonical list (that I tend to
neglect).
We d
One thing that is always missing from our release processes is the
announcements to portal websites. I don't believe the zoom in downloads for
1.3.8/2.0.8 was a coincidence -- because it was announced very loudly :-)
Make sure you also note emailing the announcement to
announce.AT.apachenews.org a
2007/9/6, Ted Husted <[EMAIL PROTECTED]>:
>
> Is there any reason why it's labeled for Struts 2.1.x? Could we also
> try it for 2.0.10?
In fact I committed the changes only for the trunk and I did not backport it
to the 2_0_X branch. If you want I can merge it to the branch.
If so, I'll give i
Struts 2 (I think that I have finished, but I need to test it to be
> sure).
> In the meantime, I prepared a wiki page that shows how the release
> process will look like:
> http://cwiki.apache.org/confluence/display/WW/Creating+and+Signing+a+Struts+2.1.x+Distribution
> Notice that
Hi all
I am in the process of finish configuring the Maven Release plugin for
Struts 2 (I think that I have finished, but I need to test it to be
sure).
In the meantime, I prepared a wiki page that shows how the release
process will look like:
http://cwiki.apache.org/confluence/display/WW/Creating
We're rolling...
I have created a new JIRA release 2.0.11:
https://issues.apache.org/struts/browse/WW/fixforversion/21860
I have started a release notes page:
http://cwiki.apache.org/confluence/display/WW/Release+Notes+2.0.10
I need to do some testing and finish updating the Release Notes. Onc
It's been while since I used Selenium but I could help on this.
musachy
On 7/31/07, Martin Gilday <[EMAIL PROTECTED]> wrote:
> > > > In
> > > > terms of reducing the actual amount of time spent on a release, a
> > > > solid set of Selenium tests might make the most difference.
> >
> > > > +1
> >
> > > In
> > > terms of reducing the actual amount of time spent on a release, a
> > > solid set of Selenium tests might make the most difference.
>
> > > +1
> > > I think that someone is already working on Selenium tests, or am I
> > > confusing with Struts 1?
> > Even if someone where, it's a ve
On 7/29/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
> 2007/7/29, Ted Husted <[EMAIL PROTECTED]>:
> > Feel free, Antonio. We'd make it simpler if we knew how, we just don't
> > know how to make it simpler and achieve the same result.
>
> I opened an issue, that presumably will be applied to the
2007/7/29, Ted Husted <[EMAIL PROTECTED]>:
> Feel free, Antonio. We'd make it simpler if we knew how, we just don't
> know how to make it simpler and achieve the same result.
I opened an issue, that presumably will be applied to the 2.1.x version family:
https://issues.apache.org/struts/browse/WW-
Feel free, Antonio. We'd make it simpler if we knew how, we just don't
know how to make it simpler and achieve the same result.
Of course, learning curve aside, clicking through the release process
isn't the time bandit. The lion's share still goes to reviewing the
tic
2007/7/29, Ted Husted <[EMAIL PROTECTED]>:
> And that's the real problem: We have too few release managers.
It is so because the release process is pretty complicated. I think
that the adoption of the Maven release plugin could help a lot (and
attract more release managers :-)
The code patches don't worry me as much as what to do about the documentation.
The docs are all under Confluence, and so there is no clean way to
fork and patch those.
Accordingly, we have to be careful that any revisions read well under
both 2.1.x and 2.0.x.
I expect that means that any 2.1.x
On 2/7/07, Ted Husted <[EMAIL PROTECTED]> wrote:
Phillip filed a number of tickets regarding WebWork fixes, so what we
haven't applied may just be pending. I know there are a couple of WW
patches slated for 2.0.6 (thanks Tom!).
And as soon as my apache account is created, I'll be committing t
Phillip filed a number of tickets regarding WebWork fixes, so what we
haven't applied may just be pending. I know there are a couple of WW
patches slated for 2.0.6 (thanks Tom!).
Overall, there are a number of patches that should be reviewed and
either applied or otherwise resolved.
*
https://i
I would argue also that a lot of fixes going into struts 2.0.x haven't made
it back into webwork. Several issues I resolved in Webwork this weekend
were already fixed in Struts 2.0.x.
Tom
On 2/7/07, Don Brown <[EMAIL PROTECTED]> wrote:
I'm fine with branching now, but it means that we need to
I'm fine with branching now, but it means that we need to be extra
careful to port fixes to all applicable branches: WebWork 2.2.x (where
applicable), Struts 2.0.x, and Struts 2.1.x. A lot of fixes have been
going into WebWork 2.2.x that haven't been making it to Struts 2.0.x,
so we need to be do
There are a few ajax issues with their patches already on jira. They are
all simple fixes and could be addressed on 2.0.6 instead of 2.1.
regards
musachy
Ted Husted wrote:
OK, I created a 2.0.x branch and I'm about to update the POMs. This
stuff is trivial to do, so if anyone is deadset agains
OK, I created a 2.0.x branch and I'm about to update the POMs. This
stuff is trivial to do, so if anyone is deadset against a branch now,
we can redo it easy enough later. Though, I'd be happy to ensure that
we backport relevant 2.1.x changes to 2.0.x, until we hit a 2.1.x GA.
I've silently bulk
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
On 2/7/07, Philip Luppens <[EMAIL PROTECTED]> wrote:
On 2/7/07, Rene Gielen <[EMAIL PROTECTED]> 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 what
On 2/7/07, mraible <[EMAIL PROTECTED]> 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 politic
We almost branched before, so let's go ahead and do it now.
My only request would be that we tkeep the new feature set for 2.1.x
manageable, so that we can move to another GA release of that series
soon. As triggers, I would suggest:
* Refactoring of Dojo and Portlet support to plugins
* Extract
On 2/7/07, Rene Gielen <[EMAIL PROTECTED]> 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 +
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 schri
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 <[EMAIL PROTECTED]> wrote:
>> I would love it if we actually did this. Unfortuna
On 2/6/07, Don Brown <[EMAIL PROTECTED]> 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. Ho
On 2/6/07, Don Brown <[EMAIL PROTECTED]> 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 undet
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 use
On 2/6/07, Craig McClanahan <[EMAIL PROTECTED]> 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 grea
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 agr
ning 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.
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 approa
On 12/30/06, Ted Husted <[EMAIL PROTECTED]> wrote:
We are quite close. The autoexport plugin automatically maintains the
HTML version, and a cron job zips it up. The problematic part is
merging the HTML download with the other documentation on the site
that is generated from other sources. It's
On 12/29/06, mraible <[EMAIL PROTECTED]> wrote:
Do you know know of a better example that uses Confluence for its
documentation?
If you find one let me know, and we'll use it too. :)
A lot of ASF projects use Confluence more and more everyday, and
developing a fully automatic release procedure
nd include
> in the distribution.
>
> All in all, I'm not so sure the Struts 2 build is a good example. :)
>
Do you know know of a better example that uses Confluence for its
documentation?
Thanks,
Matt
--
On 12/29/06, mraible <[EMAIL PROTECTED]> wrote:
I'm assuming you use the assembly plugin to create sources and javadocs?
No... that would be done with the source and javadoc plugins. It
should be happening when the "pre-assembly" profile is enabled, but I
don't actually see that defined anywh
oak-3 wrote:
>
> On 12/29/06, mraible <[EMAIL PROTECTED]> wrote:
>
>> Is there a documented release process for Struts 2?
>>
>> How do you create the JARs, sources, javadocs and upload them to a Maven
>> repo?
>>
>> We're using Maven 2 in AppF
On 12/29/06, mraible <[EMAIL PROTECTED]> wrote:
Is there a documented release process for Struts 2?
How do you create the JARs, sources, javadocs and upload them to a Maven
repo?
We're using Maven 2 in AppFuse, so I figured we could probably follow a
pre-existing solution rather
Is there a documented release process for Struts 2?
How do you create the JARs, sources, javadocs and upload them to a Maven
repo?
We're using Maven 2 in AppFuse, so I figured we could probably follow a
pre-existing solution rather than coming up with our own.
Thanks,
Matt
--
View
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 b
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
, a
release should be basically automatic, something we can trust to
another committer without looking over their shoulder.
Ok, so if you don't think this is the answer to the backwards release
then test problem, what is?
The release process isn't backward. It's the same process t
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, 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 uploa
ant changes, especially new major or minor
versions, should first be released and distributed as Alpha or Beta
quality, then later upgraded to GA if it is warranted.
The entire release process should be as easy and clear as possible.
Right now there are a couple of points where it's not easy for so
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.
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 <[
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 Brown
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.
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
I hadn't made a point of responding since the vote was already
closed, but I've come to agree that the problems identified with the
1.3.4 build are sufficient to make it a "beta", and further, I've
just identified one or two other things that are worth nothing that
probably further justify that
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 s
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, 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
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 Candid
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, 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 pr
> 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 implementation of it, is broken. A few Struts committers
> work their butts off to push out a release, clearing
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
+1 - Nicely done, Ted :-)
- Original Message -
From: "Martin Cooper" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Saturday, October 30, 2004 1:16 PM
Subject: Re: Release process ambiguities [was ... Adopt]
On Sat, 30 Oct
* http://struts.apache.org/bylaws.html
>
> Perhaps we should just rely on the checklist to detail our release process.
>
> We could drop the references to other people's guidelines and follow our own
> checklist and remarks.
>
> I've added a proposed release
> http://jakarta.apache.org/site/guidelines.html
I believe the Jakarta guidelines are the sort of thing that the board refers to as the
project bylaws, like the ones posted here:
* http://struts.apache.org/bylaws.html
Perhaps we should just rely on the checklist to detail our release proc
96 matches
Mail list logo
