On 1 May 2013 16:07, <[email protected]> wrote: > > Yes, I never managed to create new versions when I did the 1.0.0 releases > either. I kept meaning to sort it out and tidy that all up but never quite > managed it. It seems like the permissions might be a gap in our process and > at the very least PMC members should have access. > > While I'm on the subject, I'll repeat my proposal about how we manage > versions, which is that we should restrict our JIRA versions to numbers, > rather than numbers+bundle-name. Otherwise we'll rapidly hit a bit of a > combinatoric explosion where the volume of versions in the list makes it > impossible to find the right one. Numbers-only, in combination with the > component field, will allow us to pin a change down to a small number of > bundles, so it's not as loose as it first seems. In my experience many JIRAs > involve changes to more than one bundle, so I'm not sure it will even be > correct in many cases to have versions which identify a single bundle.
Have a dig around in the administration and see if you can figure out how you would do this. The idea is you create a 'version' for the code you want to release. So for example Apache CXF is a nice example: https://issues.apache.org/jira/browse/CXF#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel A Version is either 'released' or 'not released'. When we started putting the module name in the version name we were trying to solve the problem of being able to indicate that a Version was released without saying that the whole of the Aries project had been released - ie. make it specific to the module we were actually releasing. Another non-option was to ask for a JIRA project for each of the Aries modules. But that would have been against the general rule of one JIRA project per ASF project. What you're proposing would certainly be clearer, but we wouldn't want to mark a Version as released ... ever. For example marking Version 1.0 as released would mean the whole of Apache Aries had been released at version 1.0. What if we start a new module - we wouldn't be able to release that at 1.0 because we'd have already closed that Version number. So, are there any downsides to never marking Versions as released. I think it's just an administrative 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 <[email protected]> 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 the > >> rest of the release stuff, but it would be nice to track what went in... > >> > >> Tim Ward > >> ------------------- > >> Apache Aries PMC member & Enterprise OSGi advocate > >> Enterprise OSGi in Action (http://www.manning.com/cummins) > >> ------------------- > >> > >> > >>> From: [email protected] > >>> To: [email protected] > >>> 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 Ward > >>> ------------------- > >>> Apache Aries PMC member & Enterprise OSGi advocate > >>> Enterprise OSGi in Action (http://www.manning.com/cummins) > >>> ------------------- > >>> > >>> > >>>> From: [email protected] > >>>> To: [email protected] > >>>> Subject: RE: Aries Util Next Release Version > >>>> Date: Thu, 7 Mar 2013 12:06:32 +0000 > >>>> > >>>> > >>>> 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 EclipseCon (March 25th) > >>>> > >>>> Regards, > >>>> > >>>> Tim Ward > >>>> ------------------- > >>>> Apache Aries PMC member & Enterprise OSGi advocate > >>>> Enterprise OSGi in Action (http://www.manning.com/cummins) > >>>> ------------------- > >>>> > >>>> > >>>>> From: [email protected] > >>>>> Date: Tue, 12 Feb 2013 09:42:40 +0000 > >>>>> Subject: Re: Aries Util Next Release Version > >>>>> To: [email protected] > >>>>> > >>>>> On 10 February 2013 17:01, John W Ross <[email protected]> wrote: > >>>>>> 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. > >>>>> > >>>>> The versioning tool checks the versions are semantically (well > > really > >>>>> is a syntactic check) correct checking the built .class files > > against > >>>>> the previous released version. So, if there are any problems, they > >>>>> need to be corrected before a release is started. The maven release > >>>>> plugin, after creating a tag of the source being released then > > updates > >>>>> the poms in the local SVN working copy and checks them into trunk. > > As > >>>>> the person running the maven release plugin you get the > > (interactive) > >>>>> option to select the default, which is to increment the minor > > number > >>>>> of the module, or to choose your own. > >>>>> > >>>>> Perhaps there is a property for configuring the maven 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 defaults to incrementing the > > minornumber and > >>>>>>> resetting the micro number. You don't have top pick the > >> default - it's an > >>>>>>> interactive process - but maybe that's what happened :-) > >>>>>>> On Feb 8, 2013 5:30 PM, "John W Ross" <[email protected]> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> Okay, so the consensus is to have the util trunk version set > > as > >>>>>>>> 1.1.1-SNAPSHOT. > >>>>>>>> > >>>>>>>> I'm still not clear on whether or not the tool > >> automatically made the > >>>>>>>> decision to set the next version to 1.2.0-SNAPSHOT (and > >> 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. > >>>>>>>> > >>>>>>>> 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 user > >> intervention during > >>>>>>>>> the release to achieve, but which is safest, semantically. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 5 Feb 2013, at 21:05, John W Ross <[email protected]> > > wrote: > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Just to be sure we're talking about the same thing (my > > subject > >>>>>> might > >>>>>>>> have > >>>>>>>>>> been a bit misleading), the part of the version policy I'm > >>>>>> referring to > >>>>>>>> is > >>>>>>>>>> the following: > >>>>>>>>>> > >>>>>>>>>> "OSGi semantic versioning applies to bundles as well > >> as packages. > >>>>>> When > >>>>>>>>>> releasing a new version of a bundle the change in the > > bundle > >>>>>> version > >>>>>>>> should > >>>>>>>>>> give some indication of nature of the changes to the > > bundle. In > >>>>>> Aries > >>>>>>>> the > >>>>>>>>>> bundle version is the same as version of the Maven > > artifact > >>>>>> version. > >>>>>>>> During > >>>>>>>>>> development, in trunk, the Maven artifact version will be: > >>>>>>>>>> x.y.(z+1)-SNAPSHOT > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Where x.y.z is the most recent 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 Version > >>>>>>>>>>> > >>>>>>>>>>> +1 to modifying the policy. I think we need to use the > > minimal > >>>>>> version > >>>>>>>>>>> increment until proven otherwise. Otherwise we risk > > breaking > >>>>>>>> implementors > >>>>>>>>>>> of interfaces in the snapshot build every time we doa > > release. > >>>>>>>>>>> The 1.2.0-SNAPSHOT is defaulted by the release > >> plugin, but it's > >>>>>> easy > >>>>>>>>>> enough > >>>>>>>>>>> to override to the minimal increment when staging the > > release. > >>>>>>>>>>> > >>>>>>>>>>> Holly > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Feb 5, 2013 at 5:43 PM, John W Ross > >> <[email protected]> > >>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> I'm also okay with amending our version policy (not > >> sure how old > >>>>>> the > >>>>>>>>>>>> information on that web page is). I'm not sure I > >> care what the > >>>>>> trunk > >>>>>>>>>>>> snapshot version is as long as the semantic > >> versioning tool 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 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 > > <[email protected]> > >>>>>> 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 seems inconsistent with the > > version > >>>>>> policy > >>>>>>>>>>>> specified > >>>>>>>>>>>>>> at > > http://aries.apache.org/development/versionpolicy.html. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'm ok flipping them to 1.1.1-SNAPSHOT. Seems > > reasonable. > >>>>>>>>>>>>> > >>>>>>>>>>>>> That said, you'd have to login to nexus and wipe > >> out the 1.2.0- > >>>>>>>>>>>>> SNAPSHOT versions. > >>>>>>>>>>>>> > >>>>>>>>>>>>> -- > >>>>>>>>>>>>> Daniel Kulp > >>>>>>>>>>>>> [email protected] - http://dankulp.com/blog > >>>>>>>>>>>>> Talend Community Coder - http://coders.talend.com
