Return-Path: X-Original-To: apmail-aries-dev-archive@www.apache.org Delivered-To: apmail-aries-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 924F4E2B5 for ; Fri, 8 Feb 2013 17:40:39 +0000 (UTC) Received: (qmail 9929 invoked by uid 500); 8 Feb 2013 17:40:39 -0000 Delivered-To: apmail-aries-dev-archive@aries.apache.org Received: (qmail 9867 invoked by uid 500); 8 Feb 2013 17:40:39 -0000 Mailing-List: contact dev-help@aries.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@aries.apache.org Delivered-To: mailing list dev@aries.apache.org Received: (qmail 9859 invoked by uid 99); 8 Feb 2013 17:40:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Feb 2013 17:40:39 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.85.173.253] (HELO server.dankulp.com) (64.85.173.253) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Feb 2013 17:40:33 +0000 Received: by server.dankulp.com (Postfix, from userid 5000) id 8E875182B7D; Fri, 8 Feb 2013 12:40:12 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on server.dankulp.com X-Spam-Level: X-Msg-File: /tmp/mailfilter-dev@aries.apache.org.5V8ABJsWw6 Received: from macbook.house.dankulp.com (c-24-91-72-253.hsd1.ma.comcast.net [24.91.72.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.dankulp.com (Postfix) with ESMTPSA id B26F018065D; Fri, 8 Feb 2013 12:40:08 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Aries Util Next Release Version From: Daniel Kulp In-Reply-To: Date: Fri, 8 Feb 2013 12:40:07 -0500 Content-Transfer-Encoding: 7bit Message-Id: <1408DE6C-BBE1-4F2E-85F1-AD07AD109C63@apache.org> References: <061F62BC-93C8-4301-987F-10196012A527@apache.org> <6BF19CD1-7E06-4EFA-86E1-367DA9ABF1F7@googlemail.com> To: dev@aries.apache.org, John W Ross X-Mailer: Apple Mail (2.1499) X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-2.9 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00 shortcircuit=no autolearn=unavailable version=3.3.2 On Feb 8, 2013, at 12:29 PM, John W Ross 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. May have been user input. I don't remember. I'm getting old. :-) Dan > > 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 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 do a 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 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 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 >>>>>> dkulp@apache.org - http://dankulp.com/blog >>>>>> Talend Community Coder - http://coders.talend.com -- Daniel Kulp dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com