aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: Please keep JIRA issues up to date
Date Fri, 18 Feb 2011 08:59:32 GMT
I'm not sure that this is a very good idea to defer until the release.
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.  Even with a tool, you may have incompatible changes that
can't be reflected by an API change.  For example changing a default
value would require more than a micro update I think, but no tool will
really show you the semantic of the code.  The knowledge is in the guy
who actually commit the change in svn, so he should be responsible for
 that somehow.

I think any breaking change that require a major version bump should
be discussed on the mailing list to avoid having each release being a
major one.  Those changes should be defered and grouped if possible.
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).

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...  I'd love to be able
to do releases (and I plan to do some for blueprint asap), but if it
takes 2 or 3 days work to actually do all the work, I will certainly
not volunteer anymore.

On Fri, Feb 18, 2011 at 09:44, zoe slattery <> wrote:
>> I think the switch from uber release to by bundle release is going 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 Next,
>> 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-SNAPSHOT or
> something like that.
> It them becomes the responsibility of the release manager to figure 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 didn't
>> realise you could rename versions and maintain referential integrity.)
>> On 17 February 2011 19:25, Guillaume Nodet<>  wrote:
>>> Good question.   I suppose the same JIRA issue could be marked for
>>> both application-api-1.1 and application-runtime-1.3.   But there will
>>> be no 0.4 version anymore, so we would not be able to use it anyway.
>>> I honestly don't have much experience, as that's really a release
>>> 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<>  wrote:
>>>> Not meaning to be awkward, but what happens when a defect or feature
>>>> spans multiple bundles?
>>>> -- Mark
>>>> On 17 February 2011 19:05, Guillaume Nodet<>  wrote:
>>>>> 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 identified
>>>>> 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<>
>>>>>  wrote:
>>>>>> Not sure to follow.  Right now, trunk is 0.4.0-SNAPSHOT, so you
>>>>>> to use the 0.4 version.
>>>>>> See
>>>>>> 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 for example
>>>>>> 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,
>>>>>> can rename the version in JIRA wihout having to modify all the issues.
>>>>>> On Thu, Feb 17, 2011 at 19:27, Alasdair Nottingham<>
>>>>>>  wrote:
>>>>>>> How can we set the fix version prior to the release? Until the
>>>>>>> release
>>>>>>> exists we don't know what version we will choose.
>>>>>>> On 17 February 2011 17:15, Guillaume Nodet<>
>>>>>>>> While backporting issues into blueprint 0.2.x branch, I had
a hard
>>>>>>>> time to find the commits relative to ARIES-390:
>>>>>>>>  the only listed commit is actually completely unrelated.
>>>>>>>> Please guys, when you work on something, create a JIRA for
>>>>>>>> commit
>>>>>>>> with the appropriate message (so, ARIES-390, not "aries 390"
>>>>>>>> anthing else) and even put the rev number in the JIRA issue.
>>>>>>>> Also make sure the fixed version is correctly set for any
issue you
>>>>>>>> work on, and once you're done on the issue, mark it as resolved.
>>>>>>>> can always be reopened later if needed but at least it's
easer to
>>>>>>>> keep
>>>>>>>> an eye on opened issue.
>>>>>>>> JIRA is really our only way to produce correct release notes
>>>>>>>> keep
>>>>>>>> track of what's going on (well, i suppose the svn log is
>>>>>>>> one,
>>>>>>>> but it's wat less productive ...)
>>>>>>>> In that case, I found out it is rev 990084, but that wasn't
>>>>>>>> easy.
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog:
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>> --
>>>>>>> Alasdair Nottingham
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog:
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog:
>>>>> ------------------------
>>>>> Open Source SOA
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog:
>>> ------------------------
>>> Open Source SOA

Guillaume Nodet
Open Source SOA

View raw message