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