Return-Path: Delivered-To: apmail-aries-dev-archive@www.apache.org Received: (qmail 78199 invoked from network); 21 Feb 2011 10:54:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 21 Feb 2011 10:54:43 -0000 Received: (qmail 17129 invoked by uid 500); 21 Feb 2011 10:54:43 -0000 Delivered-To: apmail-aries-dev-archive@aries.apache.org Received: (qmail 16992 invoked by uid 500); 21 Feb 2011 10:54:40 -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 16974 invoked by uid 99); 21 Feb 2011 10:54:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Feb 2011 10:54:39 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of alasdair.nottingham@gmail.com designates 209.85.216.171 as permitted sender) Received: from [209.85.216.171] (HELO mail-qy0-f171.google.com) (209.85.216.171) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Feb 2011 10:54:34 +0000 Received: by qyj19 with SMTP id 19so1501774qyj.2 for ; Mon, 21 Feb 2011 02:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=/Zt/+ZQXJQDrf8VBHDt/SyJUnD0OyiUIhrA+gjKVRTQ=; b=YHvmEtq6C2lZI5Zq00h7sKfAdDiqG4EEz6PcI4ol73O9tpjPMYWFzC4DKKnKql9YEE bIMD39WnLnpp2Ki8BhxI1772xIgZtGOWl0VBnDJYoAcvy2Z/FTn8US83uzoNAwMYeUWu ADnqWzqxP4/+PlmBG5AFHJrcMWteLvcZB29IA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=s95Rqxt2gIkf/1otBYsMa3gU52Ra9pJHAX3l+9S35KYbzgLe0gA1JO3CGq0DjA19XZ h7GgfX3AyhYDYHMb0OIZzT5EsqyeHFc/o1mr7onq8nMt3RU54CgCMdUEnUdwnGRzlEdX 9zZ9RDBz89ZUQEUMOgo8bUUTOqsiCrsjHQ10c= MIME-Version: 1.0 Received: by 10.224.176.197 with SMTP id bf5mr949673qab.175.1298285652874; Mon, 21 Feb 2011 02:54:12 -0800 (PST) Sender: alasdair.nottingham@gmail.com Received: by 10.229.88.18 with HTTP; Mon, 21 Feb 2011 02:54:12 -0800 (PST) In-Reply-To: References: <4D5E316F.80100@gmail.com> Date: Mon, 21 Feb 2011 10:54:12 +0000 X-Google-Sender-Auth: SP6POzmz2W_jP0qpAlpDdDkVJSk Message-ID: Subject: Re: Please keep JIRA issues up to date From: Alasdair Nottingham To: dev@aries.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My JIRA id is "not" and I do not have access to add, delete, change or modify anything. I am in the aries-developers group, which I guess doesn't give me project admin authority. If all PMC members should have this access should we create a group for pmc members? Thanks Alasdair On 18 February 2011 13:42, Guillaume Nodet wrote: > On Fri, Feb 18, 2011 at 14:05, Alasdair Nottingham wrote= : >> On 18 February 2011 12:22, Guillaume Nodet wrote: >>> On Fri, Feb 18, 2011 at 12:50, Alasdair Nottingham wro= te: >>>> On 18 February 2011 10:10, Guillaume Nodet wrote: >>>>> On Fri, Feb 18, 2011 at 10:36, Alasdair Nottingham w= rote: >>>>>> >>>>>> >>>>>> Alasdair Nottingham >>>>>> >>>>>> On 18 Feb 2011, at 08:59, Guillaume Nodet wrote: >>>>>> >>>>>>> I'm not sure that this is a very good idea to defer until the relea= se. >>>>>>> This puts too much burden on the release manager as he needs to >>>>>>> investigate *all* the svn changes for each bundle and figure out if >>>>>>> they are backward compatible or not and thus how the version should= be >>>>>>> incremented. =A0Even with a tool, you may have incompatible changes= that >>>>>>> can't be reflected by an API change. =A0For example changing a defa= ult >>>>>>> value would require more than a micro update I think, but no tool w= ill >>>>>>> really show you the semantic of the code. =A0The knowledge is in th= e guy >>>>>>> who actually commit the change in svn, so he should be responsible = for >>>>>>> that somehow. >>>>>> >>>>>> True, but this can be reflected in the pom when the change is made. = The point is we might only make bug fixes between releases. We don't know u= ntil we do a release the nature of the changes. >>>>>> >>>>>>> >>>>>>> I think any breaking change that require a major version bump shoul= d >>>>>>> be discussed on the mailing list to avoid having each release being= a >>>>>>> major one. =A0Those changes should be defered and grouped if possib= le. >>>>>>> If we want to support maintenance releases, it kinda mean the next >>>>>>> version will always be a minor upgrade (so from 1.1 to 1.2-SNAPSHOT= ), >>>>>>> unless after discussion, the version is a major bump (to 2.0). >>>>>> >>>>>> I don't agree with this. Supporting a maintenance release does not r= equire trunk to always increment the minor version. >>>>>> >>>>> >>>>> That's true, it's not a requirement, I just think it's easier as the >>>>> process is known and reproductible. =A0 When you release, create a >>>>> branch which will later be used for maintenance. =A0 Trunk becomes ne= xt >>>>> minor (eventually major version). =A0 If you just fix a bug, backport= it >>>>> to the branch in addition to trunk (using git-svn, it's a one line >>>>> command, so that's no pain). >>>>> At least, you have a process for maintenance branches. =A0Else, you n= eed >>>>> to branch later from the tag, review all commits that have been done >>>>> on trunk and choose which one to backport. >>>>> I suppose the release manager will do that, and once again, it's >>>>> usually easier for the committer to backport a bug rather than someon= e >>>>> that don't what the bug is about. =A0When the backport is easy, it's = not >>>>> a real problem, when when you need to actually merge or rewrite the >>>>> bug fix, things become really more complicated. >>>>> >>>> >>>> I think trunk should be what we are working on now. Right now to me th= at >>>> means 0.3.1 (I know everything is 0.4 right now, but I think we are >>>> talking about >>>> futures). If at some point we do a 0.4 release that is the right point >>>> to create a >>>> maintenance branch for that bundle, module, whatever. That way we take= the >>>> "pain" only when we need to, only when we decide we need a maintenance= release. >>> >>> For blueprint, I think there are major new features, one of them you >>> just added yesterday as ARIES-577 >>> so it clearly isn't a 0.3.1 to me. >>> 0.3.1 is what i've been doing yesterday and it's located in >>> =A0http://svn.apache.org/repos/asf/aries/branches/0.3-RCx/blueprint/ >>> it only contain bug fixes. >>> >>> Or maybe we have a misunderstanding of what a maintenance release is ..= . >>> >> >> I agree blueprint isn't, a 0.3.1 release, but that is irrelevant to my >> point. I am trying to talk about >> the general case, not about the specifics of the current state of svn. >> I'm talking about how we >> =A0do this going forward and for the next x years. >> >> >>>>>>> >>>>>>> The release manager job should be made as easy as possible, that's = why >>>>>>> JIRA issues need to be kept up to date for release notes, versions >>>>>>> known before hand, things tested together, etc... =A0I'd love to be= able >>>>>>> to do releases (and I plan to do some for blueprint asap), but if i= t >>>>>>> takes 2 or 3 days work to actually do all the work, I will certainl= y >>>>>>> not volunteer anymore. >>>>>>> >>>>>> >>>>>> Easy is good, I didn't realise JIRA made that really hard. >>>>> >>>>> Well, if you have another tool of producing release notes easily and >>>>> track issues at the same time in multiple branches, I'd be happy to >>>>> switch. =A0Let me know what your magic tool is. =A0Of course, if the >>>>> solution is just to not track things, it obviously make things easier >>>>> ... for us, not sure about the user that want to know in which bundle >>>>> a problem has been fixed. >>>>> >>>>> Easy is good, but it seems you want to let the release manager do all >>>>> the work, from figuring which versions should be used for packages, >>>>> bundles, which problem have been fixed and all. =A0I don't really >>>>> understand ... =A0Easy for developers ? or easy for the release manag= er >>>>> ? >>>> >>>> I don't understand your point here. I was trying to point out that unt= il >>>> we do a release we don't know what the version number will be. >>>> =A0I was >>>> suggesting that rather than set it to 0.4 and then having to change it= to >>>> 0.3.1 if our next release is 0.3.1 we could go with .Next (or as Zoe s= uggests >>>> -SNAPSHOT) and then rename it from -SNAPSHOT to 0.3.1 or 0.4 or 1.0 ba= sed >>>> on the version we release. I didn't think changing a version in JIRA w= as hard. >>>> >>> >>> Changing a version in JIRA is really easy. =A0The problem is the >>> semantic and the choice of the version number. >>> Let's imagine for a second that you are a release manager and you want >>> to release application. How do you know if you need to release 0.3.1, >>> 0.4.0 or 1.0 ? >>> >> >> Good I am glad it is easy. Given that a relatively few people seem to ha= ve >> enough access to JIRA to change the versions I don't think we should be = using >> JIRA to work out what the next level should be. > > All pmc members should be able to do that, I don't really why that > would not be the case. =A0If you can't, let me (or Jeremy) know your > JIRA id and we'll fix that. > >> I think the best thing >> to do is when >> we do a release we increment the micro version in trunk, e.g. 0.3 -> >> 0.3.1 and if >> someone makes a change that requires a minor or major version increment = they >> update the relevant poms and put it into svn. At release time we can >> check to ensure >> we haven't gone from 0.3 -> 0.6 and collapse down if necessary. Then >> when tidying up >> JIRA we rename the -SNAPSHOT version to the relevant number e.g. 0.4 >> and create a new >> -SNAPSHOT. That doesn't sound too difficult or burdensome to the >> release manager to me. > > That doesn't look too bad to me either, but then it would also be easy > that the same guy that change the pom change the jira version too. > But still, i'd rather have a process where maintenance branches would > be first class citizen, else releasing bug fix releases will require > much more work than required. > It's way easier to backport a fix when you actually develop it, rather > than let a release manager backport everything a few months later (and > running into merge problems). > >> >>> >>>>> >>>>>> >>>>>>> On Fri, Feb 18, 2011 at 09:44, zoe slattery wrote: >>>>>>>>> I think the switch from uber release to by bundle release is goin= g to >>>>>>>>> have to deal with this. Once we have done that fixes that span >>>>>>>>> multiple bundles would be tagged with multiple versions. >>>>>>>>> >>>>>>>>> Based on this would it make more sense if the version was named N= ext, >>>>>>>>> rather than 0.4? Then we would rename Next to 0.4 at release time= and >>>>>>>>> then create a new Next? >>>>>>>> >>>>>>>> Yes - you can do that. I was thinking it might be called DEV-SNAPS= HOT or >>>>>>>> something like that. >>>>>>>> It them becomes the responsibility of the release manager to figur= e out what >>>>>>>> has changed and re-name the bundle >>>>>>>> appropriately. With some help from a tool this might work. >>>>>>>> Z >>>>>>>>> >>>>>>>>> It would certainly make this a little more obvious to me (who did= n't >>>>>>>>> realise you could rename versions and maintain referential integr= ity.) >>>>>>>>> >>>>>>>>> On 17 February 2011 19:25, Guillaume Nodet =A0w= rote: >>>>>>>>>> >>>>>>>>>> Good question. =A0 I suppose the same JIRA issue could be marked= for >>>>>>>>>> both application-api-1.1 and application-runtime-1.3. =A0 But th= ere will >>>>>>>>>> be no 0.4 version anymore, so we would not be able to use it any= way. >>>>>>>>>> I honestly don't have much experience, as that's really a releas= e >>>>>>>>>> scheme I've never used as I don't think it scales really well to= big >>>>>>>>>> projects. >>>>>>>>>> >>>>>>>>>> On Thu, Feb 17, 2011 at 20:16, Mark Nuttall= =A0wrote: >>>>>>>>>>> >>>>>>>>>>> Not meaning to be awkward, but what happens when a defect or fe= ature >>>>>>>>>>> spans multiple bundles? >>>>>>>>>>> >>>>>>>>>>> -- Mark >>>>>>>>>>> >>>>>>>>>>> On 17 February 2011 19:05, Guillaume Nodet = =A0wrote: >>>>>>>>>>>> >>>>>>>>>>>> Btw, when we switch to a per-bundle release cycle (as it seems= to be >>>>>>>>>>>> where we're heading), each bundle version will have to be iden= tified >>>>>>>>>>>> in JIRA so that we can keep track of release notes. >>>>>>>>>>>> So we'll have blueprint-core-0.4 etc ... >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Feb 17, 2011 at 20:03, Guillaume Nodet >>>>>>>>>>>> =A0wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Not sure to follow. =A0Right now, trunk is 0.4.0-SNAPSHOT, so= you need >>>>>>>>>>>>> to use the 0.4 version. >>>>>>>>>>>>> See https://issues.apache.org/jira/browse/ARIES/fixforversion= /12316139 >>>>>>>>>>>>> >>>>>>>>>>>>> If you backport a bug to a branch, it should be added too, so= i've >>>>>>>>>>>>> just added a blueprint-0.2.1 version and used it on the JIRA = i >>>>>>>>>>>>> backported, >>>>>>>>>>>>> See https://issues.apache.org/jira/browse/ARIES-435 for examp= le >>>>>>>>>>>>> >>>>>>>>>>>>> It doesn't really matter which name the version is, it's more= about >>>>>>>>>>>>> which branch. >>>>>>>>>>>>> For example, if we decide next version will be 1.0 instead of= 0.4, we >>>>>>>>>>>>> can rename the version in JIRA wihout having to modify all th= e issues. >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Feb 17, 2011 at 19:27, Alasdair Nottingham >>>>>>>>>>>>> =A0wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> How can we set the fix version prior to the release? Until t= he >>>>>>>>>>>>>> release >>>>>>>>>>>>>> exists we don't know what version we will choose. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 17 February 2011 17:15, Guillaume Nodet= =A0wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> While backporting issues into blueprint 0.2.x branch, I had= a hard >>>>>>>>>>>>>>> time to find the commits relative to ARIES-390: >>>>>>>>>>>>>>> =A0the only listed commit is actually completely unrelated. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please guys, when you work on something, create a JIRA for = it, >>>>>>>>>>>>>>> commit >>>>>>>>>>>>>>> with the appropriate message (so, ARIES-390, not "aries 390= " or >>>>>>>>>>>>>>> anthing else) and even put the rev number in the JIRA issue= . >>>>>>>>>>>>>>> Also make sure the fixed version is correctly set for any i= ssue you >>>>>>>>>>>>>>> work on, and once you're done on the issue, mark it as reso= lved. =A0It >>>>>>>>>>>>>>> can always be reopened later if needed but at least it's ea= ser to >>>>>>>>>>>>>>> keep >>>>>>>>>>>>>>> an eye on opened issue. >>>>>>>>>>>>>>> JIRA is really our only way to produce correct release note= s and >>>>>>>>>>>>>>> keep >>>>>>>>>>>>>>> track of what's going on (well, i suppose the svn log is an= other >>>>>>>>>>>>>>> one, >>>>>>>>>>>>>>> but it's wat less productive ...) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In that case, I found out it is rev 990084, but that wasn't= really >>>>>>>>>>>>>>> easy. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> Guillaume Nodet >>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>>>> Open Source SOA >>>>>>>>>>>>>>> http://fusesource.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Alasdair Nottingham >>>>>>>>>>>>>> not@apache.org >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Guillaume Nodet >>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>>>>>> ------------------------ >>>>>>>>>>>>> Open Source SOA >>>>>>>>>>>>> http://fusesource.com >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Guillaume Nodet >>>>>>>>>>>> ------------------------ >>>>>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>>>>> ------------------------ >>>>>>>>>>>> Open Source SOA >>>>>>>>>>>> http://fusesource.com >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Cheers, >>>>>>>>>> Guillaume Nodet >>>>>>>>>> ------------------------ >>>>>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>>>>> ------------------------ >>>>>>>>>> Open Source SOA >>>>>>>>>> http://fusesource.com >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Cheers, >>>>>>> Guillaume Nodet >>>>>>> ------------------------ >>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>> ------------------------ >>>>>>> Open Source SOA >>>>>>> http://fusesource.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> Guillaume Nodet >>>>> ------------------------ >>>>> Blog: http://gnodet.blogspot.com/ >>>>> ------------------------ >>>>> Open Source SOA >>>>> http://fusesource.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Alasdair Nottingham >>>> not@apache.org >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >>> >> >> >> >> -- >> Alasdair Nottingham >> not@apache.org >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > --=20 Alasdair Nottingham not@apache.org