David, I fully agree. Unless it actually passes a vote, any tag in SVN is just 'temporary'. The source tar balls are really what we need to be reviewing anyways.
On Fri, Sep 18, 2009 at 3:28 AM, David Jencks <[email protected]>wrote: > I went to some trouble a while back to set up the build to be more up to > date and use the latest release technology but I don't seem to have updated > the instructions. It looks to me as if the release candidate is technically > fine from the artifacts generated. As noted below, I'm strongly -1 on > releasing things labelled RC1 etc. Since Dejan has just gone through the > process he's probably best qualified to write accurate instructions but I > can have a go if people would prefer. > > On Sep 17, 2009, at 5:23 PM, Bruce Snyder wrote: > > On Thu, Sep 17, 2009 at 4:24 PM, Hiram Chirino <[email protected]> wrote: >> >> It's been deployed to a staging repo. See my earlier reply about that in >>> this thread. >>> >> >> Then we should probably vote on and release that module separately and >> before the full ActiveMQ release. The ActiveMQ release candidates >> shouldn't make use of candidate modules located in temporary repos. >> > > I don't see the point of this rule as long as the vote using the > not-yet-released artifact mentions that it depends on the > not-yet-released-artifact's vote. We do this all the time in geronimo. > > >> Also, why has there been no discussion regarding the preparation for >>>> this release on the dev list? >>>> >>>> >>>> Isn't that what what's going on now? >>> >>> IMHO rolling release candidates is the best way to get folks engaged and >>> discussing the current state of the product and whats still missing. >>> >> >> Agreed. >> >> As we have long seen in the History of ActiveMQ releases.. it typically >>> takes several release candidates before everyone's happy. I guess this >>> first release candidate was no different! >>> >> >> > My idea of a release candidate is a bunch of artifacts in a nexus staging > repo that we vote on. If the vote passes, we promote them, if the vote > fails we drop them and remove the tag they were built from. As such the > stuff in the repo and tag needs to be what we want to release, including > correct release version numbers. > > Agreed, release candidates are the best way to seek consensus for a >> release. To improve upon the way we go about handling releases, I'd >> like to suggest a couple minor changes: >> >> * Since tags are supposed to be a snapshot in time and therefore >> shouldn't change, I'd like to suggest that the tag name be changed to >> reflect the fact that it's a release candidate, e.g., >> activemq-5.3.0-RC1, etc. Either that or we could instead work from a >> branch that can change as much as necessary until there's agreement on >> which candidate to release. >> > > I don't understand what you are suggesting here. Has someone proposed > changing the tag created by the release plugin? > > >> * I'd also like to suggest that tarballs and zips for each release >> candidate be labeled as such, e.g., >> apache-activemq-5.3.0-RC1-bin.tar.gz, >> apache-activemq-5.3.0-RC2-bin.tar.gz, etc. This way there is no >> confusion and downloaded items are clearly marked as a release >> candidate and not a full 5.3 release. >> > > Unless you plan to publish these RCx as real releases after voting on them, > IMO this is a terrible idea. After we find something that's acceptable we > would have to remove the tag we just decided was OK and re-release with a > new name. > > >> Also, while we're discussing releases, we should make sure that the >> release guide reflects the latest practices: >> >> http://activemq.apache.org/release-guide.html >> >> I see that it needs to be updated to include the process for release >> candidates. >> >> That's why I'm grateful to anyone who take the initiative to start >>> rolling >>> the release candidates. They are basically taking on a tough job and >>> prodding the rest of to get involved the release! >>> >> > Releasing is amazingly time consuming, even with the latest greatest maven > tooling. I wouldn't have minded an email saying "I'm gonna push a release > candidate tomorrow" but this release has been on deck for months now.... I'm > not complaining now that there's some action. > > > >>> We really do need to start doing releases more often. >>> >> >> +1 to releasing more often. We should probably aim for more frequent >> minor releases, i.e., 5.2.1, 5.2.2, etc. so fixes are delivered >> faster. >> > > Wishing for more releases is great, but its hard to believe the amount of > time it takes to prepare a release candidate. I'll be really happy to see > 5.3 released. > > thanks > david jencks > > >> Bruce >> -- >> perl -e 'print >> unpack("u30","D0G)u8...@4vyy9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" >> );' >> >> ActiveMQ in Action: http://bit.ly/2je6cQ >> Blog: http://bruceblog.org/ >> Twitter: http://twitter.com/brucesnyder >> > > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://fusesource.com/
