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 10:10:39 GMT
On Fri, Feb 18, 2011 at 10:36, Alasdair Nottingham <> wrote:
> 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 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.
> 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 until we do a release the nature of the
>> 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).
> I don't agree with this. Supporting a maintenance release does not require 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.   When you release, create a
branch which will later be used for maintenance.   Trunk becomes next
minor (eventually major version).   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.  Else, you need
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 someone
that don't what the bug is about.  When 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.

>> 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.
> 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.  Let me know what your magic tool is.  Of 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.  I don't really
understand ...  Easy for developers ? or easy for the release manager

>> 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<>
>>>>>> 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<>
>>>>>>> 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 need
>>>>>>>> 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
>>>>>>>> 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, we
>>>>>>>> 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 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 issue you
>>>>>>>>>> work on, and once you're done on the issue, mark
it as resolved.  It
>>>>>>>>>> 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 and
>>>>>>>>>> keep
>>>>>>>>>> track of what's going on (well, i suppose the svn
log is another
>>>>>>>>>> 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:
>>>>>>>>>> ------------------------
>>>>>>>>>> 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
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog:
>> ------------------------
>> Open Source SOA

Guillaume Nodet
Open Source SOA

View raw message