You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Gary Tully <ga...@gmail.com> on 2008/09/09 11:32:58 UTC

ActiveMQ release process - two queries

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:
http://people.apache.org/~gtully/staging-repos/activemq-5.2/org/apache/activemq/apache-activemq/5.2

Thanks,
Gary.

Re: ActiveMQ release process - two queries

Posted by Gary Tully <ga...@gmail.com>.
thanks Jim, and I guess it is not typical to have a 5.1.1.1 so three
will very much be the norm. I can live with that.

2008/9/9 Jim Gomes <e....@gmail.com>:
> 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 <ga...@gmail.com> 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:
>>
>> http://people.apache.org/~gtully/staging-repos/activemq-5.2/org/apache/activemq/apache-activemq/5.2
>>
>> Thanks,
>> Gary.
>>
>

Re: ActiveMQ release process - two queries

Posted by Gary Tully <ga...@gmail.com>.
have update the release guide, all good. thanks.

2008/9/9 Hiram Chirino <hi...@hiramchirino.com>:
> +1
>
> 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 <e....@gmail.com> 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 <ga...@gmail.com> 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:
>>>
>>> http://people.apache.org/~gtully/staging-repos/activemq-5.2/org/apache/activemq/apache-activemq/5.2
>>>
>>> Thanks,
>>> Gary.
>>>
>>
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://open.iona.com
>

Re: ActiveMQ release process - two queries

Posted by Hiram Chirino <hi...@hiramchirino.com>.
+1

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 <e....@gmail.com> 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 <ga...@gmail.com> 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:
>>
>> http://people.apache.org/~gtully/staging-repos/activemq-5.2/org/apache/activemq/apache-activemq/5.2
>>
>> Thanks,
>> Gary.
>>
>



-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

Re: ActiveMQ release process - two queries

Posted by Jim Gomes <e....@gmail.com>.
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 <ga...@gmail.com> 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:
>
> http://people.apache.org/~gtully/staging-repos/activemq-5.2/org/apache/activemq/apache-activemq/5.2
>
> Thanks,
> Gary.
>

Re: ActiveMQ release process - two queries

Posted by Bruce Snyder <br...@gmail.com>.
On Tue, Sep 9, 2008 at 3:32 AM, Gary Tully <ga...@gmail.com> 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?

The assembly is named apache-activemq so I don't think we should
change the name of the activemq-parent to just activemq. We should
just document this in the release guide:

http://activemq.apache.org/release-guide.html#ReleaseGuide-CreatingtheActiveMQ5.xand4.xRelease,Newmethodusingreleaseandstagingplugins

> 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.

+1 for continuing the use of three digit versioning.

Bruce
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

Apache ActiveMQ - http://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/

Blog: http://bruceblog.org/