activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: ActiveMQ release process - two queries
Date Tue, 09 Sep 2008 16:28:55 GMT

I think most folks understand that a:
 * x or x.0 release is a major release, may not be backward compatible
with previous releases.
 * x.y or x.y.0 is a minor release with bug fixes some enhancements
but is backward compatible with x.0
 * x.y.z is bug fix release which should only contain bug fixes and is
just used to stabilize the x.y.0 release

but of consistency we should include all 3 number in the release so a
major would be x.0.0

On Tue, Sep 9, 2008 at 11:02 AM, Jim Gomes <> wrote:
> Hi Gary,
> I don't know anything about the ActiveMQ release process, but I will
> chime-in on the version numbering.  I think the three-digit numbering should
> be kept.  It makes things very consistent.  I am not a fan of long strings
> of version numbers, but I think the three digits are the minimum necessary
> to convey all of the import information about the build.  If we know that
> there might be minor rev numbers (i.e., the third digit), then that number
> should always be present for easier sorting/comparison either by a human or
> a computer.
> That's my $0.02.0 cents.  :)
> - Jim
> On Tue, Sep 9, 2008 at 2:32 AM, Gary Tully <> wrote:
>> Hi,
>> In cutting a first release candidate of AMQ 5.2 two small issues arise
>> that mean a re-cut.
>> 1) I accepted the maven release default version numbers, and based of
>> the parent pom the svn tag is activemq-parent-5.2.
>> I guess I should have inserted a different value at the prompt during
>> release to make it activemq-5.2 , but is a little error prone.
>> I am wondering if the parent pom changed its name to activemq, how
>> damaging would that be?
>> From a release perspective, it means that we just hit return (accept
>> defaults) during the release execution.
>> Maven activemq dependencies are typically on activemq-core. Would
>> anyone notice a change to the name of the parent pom?
>> 2) the number of digits in the version number, why the extra 0?
>> I see 4.1, then 5.1.0, but in the poms, we have 5.2. Has this been
>> discussed and what is the outcome? I like the idea of keeping the
>> version digits at a minimum.
>> 5.1, 5.1.0, 5.1.1 etc. but not 5.1.0.
>> FWIW, the current candidate is at:
>> Thanks,
>> Gary.



Open Source SOA

View raw message