On Sun, Aug 16, 2009 at 11:53 AM, Wes Wannemacher<w...@wantii.com> wrote: > On Sunday 16 August 2009 02:40:38 pm Martin Cooper wrote: >> On Sun, Aug 16, 2009 at 11:31 AM, Wes Wannemacher<w...@wantii.com> wrote: >> > On Sunday 16 August 2009 02:13:26 pm Martin Cooper wrote: >> >> If this was built against a new and unreleased struts-master, then my >> >> vote is -1. We need to vote to release the new struts-master before we >> >> can vote on the new struts-annotations build. >> > >> > http://people.apache.org/builds/struts/struts-annotations-1.0.5/m2-stagin >> >g- repository/org/apache/struts/struts-annotations/1.0.5/struts- >> > annotations-1.0.5.pom >> > >> > It's released against a released struts-master. It is released against v4 >> > though and it looks like I released v5 of struts-master >> >> Um, no, you didn't. You may have run the Maven release plugin, but >> there was no vote, so there is no release. >> > > Martin, I don't want to split hairs here
This is not splitting hairs, it is fundamental to the way the ASF works. By definition, a release *must* be voted on by the PMC. If it wasn't voted on, then it isn't a release. A release might be GA, or Beta or even Alpha, but it must have been voted as such by the PMC. Maven confuses the issue because it has a release plugin that does *not* build ASF releases; it builds what Maven chooses to call releases, and what we call simply builds. A build (or sometimes 'test build') is what may go up for vote in order for it to become a release. While the page you referenced uses the term 'distribution', I don't like that term because it implies that it is something for users to use. It is not. Only developers (defined as people who follow the -dev list) see 'distributions', or builds, and those artifacts are not intended for consumption by users (defined as people who do not follow the -dev list). Once a build has gone thought a vote on the -dev list, it either becomes a release (GA, Beta, or Alpha) or doesn't. If it doesn't, it dies, and should not be available for users to consume. If it does, we push it do the mirrors and make an announcement. Note that before we started using the Maven release plugin, no build would go to the Maven repo until it was voted to be a release. That is the down side of using the plugin - if we use it, and the vote fails, then we need to remove the artifacts it pushed to the Maven repo to that they are not misinterpreted as releases. -- Martin Cooper > , but I think you are saying that it > is not a GA release. There have been other "releases" that are sitting in > apache space that aren't GA. Of course, this could be me misunderstanding the > release process, but I always thought of the process as going this way - > > 1. someone goes through the maven release song-and-dance > 2. we all vote > 3. we let the community know the results if the vote results in our agreeing > that we will support it. > >> > and didn't update this >> > one. IMO, it probably doesn't matter, since there are bound to be a few >> > artifacts that point to old struts-master. >> > >> > We can either fail this release and I'll run another one with >> > struts-master 5 as the parent, then release again some day after the >> > parent is released. Or leave this release GA (since it did pass tests and >> > get enough votes) and just try harder next time to make sure it is >> > pointed at the latest released parent artifacts... I'm indifferent, this >> > is an internal tool, but I wanted a release (GA or not) so that I could >> > continue an internal project (maven release plugin doesn't like SNAPSHOT >> > dependencies, but doesn't care about votes). >> >> If it doesn't _need_ to be built against the latest, unreleased, >> struts-master, there's no need to change anything. >> >> I will point out again, though, that just running the Maven release >> plugin does *not* constitute a release. It's only a release if there >> is a PMC vote to make it a release. If a release vote fails, for >> whatever reason, then any artifact that was automatically uploaded by >> Maven must be removed, so that it is not misinterpreted as a release. >> > > Again, what I meant is that it is not a GA release. The version # can't be > resurrected (at least not without significant SVN changes) so, IMO, it's > released, just that it is not something that we are supporting. > > Given the side effects of this process though, I understand what you are > saying. The last time a release failed voting, there were still remnants > sitting around (2.1.7), but I don't think this is the first time we have run > the release process, only to have a set of unsupported jars. > > //5 minutes later after looking to see if there is anything to backup my > insane ramblings - > > Given some quick research, I guess instead of "release" I should be using the > term "distribution" - > > http://struts.apache.org/kickstart.html#releases > > -Wes > > -- > Wes Wannemacher > > Head Engineer, WanTii, Inc. > Need Training? Struts, Spring, Maven, Tomcat... > Ask me for a quote! > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
