activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <chir...@gmail.com>
Subject Re: [VOTE] ActiveMQ 5.3.0
Date Fri, 18 Sep 2009 13:00:57 GMT
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 <david_jencks@yahoo.com>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 <chirino@gmail.com> 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)U8V4\@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/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message