istrative feature rather than being connected
to any particular process. So you may be onto something here.
Any JIRA experts care to comment?
Thanks,
Jeremy
>
>
> On 1 May 2013, at 15:39, John W Ross wrote:
>
> > Me too, please.
> >
> > John
> >
> >&g
ntify a single bundle.
>
>
> On 1 May 2013, at 15:39, John W Ross wrote:
>
> > Me too, please.
> >
> > John
> >
> >>
> >> RE: Aries Util Next Release Version
> >>
> >> How do I get permission to create new Versions in JIRA? I
Nevermind then :) I'll need to figure out how to track subsystem versions
at some point, though. I see a generic "1.0" version already exists that I
suppose I can use. Note there are no generic versions beyond 1.0.
John
>
> Re: Aries Util Next Release Version
>
> Hi
ect in many cases to have
versions which identify a single bundle.
On 1 May 2013, at 15:39, John W Ross wrote:
> Me too, please.
>
> John
>
>>
>> RE: Aries Util Next Release Version
>>
>> How do I get permission to create new Versions in JIRA? I can do th
ice to track what went in...
>
> Tim Ward
> ---
> Apache Aries PMC member & Enterprise OSGi advocate
> Enterprise OSGi in Action (http://www.manning.com/cummins)
> ---
>
>
> > From: timothyjw...@apache.org
> > To: dev@aries.apache.org
&g
Me too, please.
John
>
> RE: Aries Util Next Release Version
>
> How do I get permission to create new Versions in JIRA? I can do the
> rest of the release stuff, but it would be nice to track what went in...
>
> Tim Ward
> ---
> Apache Aries PMC member
mins)
---
> From: timothyjw...@apache.org
> To: dev@aries.apache.org
> Subject: RE: Aries Util Next Release Version
> Date: Wed, 1 May 2013 09:43:55 +0100
>
> Nobody looks to be doing this, but since nobody has objected either I'll get
> going with it :)
> Tim Wa
rg
> To: dev@aries.apache.org
> Subject: RE: Aries Util Next Release Version
> Date: Thu, 7 Mar 2013 12:06:32 +
>
>
> Does anyone feel like testing this out?
>
> I'd love to see a 1.1.1 release of util including ARIES-1024 in time for
> Eclipse
m/cummins)
---
> From: hugh...@apache.org
> Date: Tue, 12 Feb 2013 09:42:40 +
> Subject: Re: Aries Util Next Release Version
> To: dev@aries.apache.org
>
> On 10 February 2013 17:01, John W Ross wrote:
> > Okay. I thought our versioning tool was doing this.
n release plugin
to provide a default to the user where the micro number has been
incremented instead of the minor. I haven't seen one, but then I
haven't looked :-)
>
> John
>
>>
>> Re: Aries Util Next Release Version
>>
>> The Maven release plugin defaul
Okay. I thought our versioning tool was doing this. We presumably have no
control over the default settings in the maven release plugin and will need
to remember to override the default.
John
>
> Re: Aries Util Next Release Version
>
> The Maven release plugin defaults to incrementi
ngs to match our
> version policy) or if that was a user decision.
>
> John
>
> >
> > Re: Aries Util Next Release Version
> >
> > Oh, sorry, I might have got muddled about what we currently
> > suggested doing and what bit of the instructions we were changin
therefore needs to
> be adjusted since I think we would want the default settings to match our
> version policy) or if that was a user decision.
May have been user input. I don't remember. I'm getting old. :-)
Dan
>
> John
>
>>
>> Re: Aries Util Next Rele
match our
version policy) or if that was a user decision.
John
>
> Re: Aries Util Next Release Version
>
> Oh, sorry, I might have got muddled about what we currently
> suggested doing and what bit of the instructions we were changing.
> +1 for 1.1.1-SNAPSHOT, which may need some u
ool would
> detect
>>> that a minor version increment is not necessary (if applicable) at
> release
>>> time and make the released version 1.1.1.
>>>
>>> Also, if we decide to adhere to the version policy as stated, was the
>>> 1.2.0-SNAPSHOT automa
> version
> > in trunk would be 1.1.(0+1) instead of 1.2.0. You're saying you would
> like
> > to modify the policy and keep the 1.2.0-SNAPSHOT version in trunk?
> >
> > John
> >
> > >
> > > Re: Aries Util Next Release Version
> > >
>
undle"
>
> The most recent release of util is 1.1.0. This implies the artifact version
> in trunk would be 1.1.(0+1) instead of 1.2.0. You're saying you would like
> to modify the policy and keep the 1.2.0-SNAPSHOT version in trunk?
>
> John
>
> >
> > Re: Ar
release of the bundle"
The most recent release of util is 1.1.0. This implies the artifact version
in trunk would be 1.1.(0+1) instead of 1.2.0. You're saying you would like
to modify the policy and keep the 1.2.0-SNAPSHOT version in trunk?
John
>
> Re: Aries Util Next Release
enerated by the tool (i.e. would something
> need to be fixed there) or is that decided by the user?
>
> John
>
> >
> > Re: Aries Util Next Release Version
> >
> >
> > On Feb 5, 2013, at 9:37 AM, John W Ross wrote:
> > > I noticed that after the
e
time and make the released version 1.1.1.
Also, if we decide to adhere to the version policy as stated, was the
1.2.0-SNAPSHOT automatically generated by the tool (i.e. would something
need to be fixed there) or is that decided by the user?
John
>
> Re: Aries Util Next Release Version
>
On Feb 5, 2013, at 9:37 AM, John W Ross wrote:
> I noticed that after the 1.1.0 release, the next version for aries util was
> marked as 1.2.0-SNAPSHOT. I'm just curious if it's correct to automatically
> assume another minor version increment or if it should really be
> 1.1.1-SNAPSHOT. 1.2.0 see
I noticed that after the 1.1.0 release, the next version for aries util was
marked as 1.2.0-SNAPSHOT. I'm just curious if it's correct to automatically
assume another minor version increment or if it should really be
1.1.1-SNAPSHOT. 1.2.0 seems inconsistent with the version policy specified
at ht
22 matches
Mail list logo