You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Guillaume Nodet <gn...@gmail.com> on 2011/02/17 18:15:09 UTC
Please keep JIRA issues up to date
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: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Please keep JIRA issues up to date
Posted by Guillaume Nodet <gn...@gmail.com>.
Well, it's not really a JIRA group, it's a project role which can be changed at:
https://issues.apache.org/jira/secure/project/ViewProjectRoleActors.jspa?projectRoleId=10011&projectId=12310981
I've just added you to the PMC role which should automatically give
you administration karma on Aries JIRA project.
On Mon, Feb 21, 2011 at 11:58, Guillaume Nodet <gn...@gmail.com> wrote:
> There is a group for PMC members, and I'll add you into it now.
>
> On Mon, Feb 21, 2011 at 11:54, Alasdair Nottingham <no...@apache.org> wrote:
>> 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 <gn...@gmail.com> wrote:
>>> On Fri, Feb 18, 2011 at 14:05, Alasdair Nottingham <no...@apache.org> wrote:
>>>> On 18 February 2011 12:22, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>> On Fri, Feb 18, 2011 at 12:50, Alasdair Nottingham <no...@apache.org> wrote:
>>>>>> On 18 February 2011 10:10, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>> On Fri, Feb 18, 2011 at 10:36, Alasdair Nottingham <no...@apache.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Alasdair Nottingham
>>>>>>>>
>>>>>>>> On 18 Feb 2011, at 08:59, Guillaume Nodet <gn...@gmail.com> 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 changes.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> I think trunk should be what we are working on now. Right now to me that
>>>>>> 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
>>>>> http://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
>>>> do 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... 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
>>>>>>> ?
>>>>>>
>>>>>> I don't understand your point here. I was trying to point out that until
>>>>>> we do a release we don't know what the version number will be.
>>>>>> I 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 suggests
>>>>>> -SNAPSHOT) and then rename it from -SNAPSHOT to 0.3.1 or 0.4 or 1.0 based
>>>>>> on the version we release. I didn't think changing a version in JIRA was hard.
>>>>>>
>>>>>
>>>>> Changing a version in JIRA is really easy. The 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 have
>>>> 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. If 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 <zo...@gmail.com> 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<gn...@gmail.com> 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<mn...@apache.org> 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<gn...@gmail.com> 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<gn...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Not sure to follow. Right 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 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<no...@apache.org>
>>>>>>>>>>>>>>> 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<gn...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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: 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
>>>
>>
>>
>>
>> --
>> 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
Re: Please keep JIRA issues up to date
Posted by Guillaume Nodet <gn...@gmail.com>.
There is a group for PMC members, and I'll add you into it now.
On Mon, Feb 21, 2011 at 11:54, Alasdair Nottingham <no...@apache.org> wrote:
> 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 <gn...@gmail.com> wrote:
>> On Fri, Feb 18, 2011 at 14:05, Alasdair Nottingham <no...@apache.org> wrote:
>>> On 18 February 2011 12:22, Guillaume Nodet <gn...@gmail.com> wrote:
>>>> On Fri, Feb 18, 2011 at 12:50, Alasdair Nottingham <no...@apache.org> wrote:
>>>>> On 18 February 2011 10:10, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>> On Fri, Feb 18, 2011 at 10:36, Alasdair Nottingham <no...@apache.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Alasdair Nottingham
>>>>>>>
>>>>>>> On 18 Feb 2011, at 08:59, Guillaume Nodet <gn...@gmail.com> 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 changes.
>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>
>>>>>
>>>>> I think trunk should be what we are working on now. Right now to me that
>>>>> 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
>>>> http://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
>>> do 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... 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
>>>>>> ?
>>>>>
>>>>> I don't understand your point here. I was trying to point out that until
>>>>> we do a release we don't know what the version number will be.
>>>>> I 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 suggests
>>>>> -SNAPSHOT) and then rename it from -SNAPSHOT to 0.3.1 or 0.4 or 1.0 based
>>>>> on the version we release. I didn't think changing a version in JIRA was hard.
>>>>>
>>>>
>>>> Changing a version in JIRA is really easy. The 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 have
>>> 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. If 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 <zo...@gmail.com> 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<gn...@gmail.com> 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<mn...@apache.org> 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<gn...@gmail.com> 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<gn...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not sure to follow. Right 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 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<no...@apache.org>
>>>>>>>>>>>>>> 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<gn...@gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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: 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
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Please keep JIRA issues up to date
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gn...@gmail.com> wrote:
> On Fri, Feb 18, 2011 at 14:05, Alasdair Nottingham <no...@apache.org> wrote:
>> On 18 February 2011 12:22, Guillaume Nodet <gn...@gmail.com> wrote:
>>> On Fri, Feb 18, 2011 at 12:50, Alasdair Nottingham <no...@apache.org> wrote:
>>>> On 18 February 2011 10:10, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>> On Fri, Feb 18, 2011 at 10:36, Alasdair Nottingham <no...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>> Alasdair Nottingham
>>>>>>
>>>>>> On 18 Feb 2011, at 08:59, Guillaume Nodet <gn...@gmail.com> 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 changes.
>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>
>>>> I think trunk should be what we are working on now. Right now to me that
>>>> 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
>>> http://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
>> do 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... 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
>>>>> ?
>>>>
>>>> I don't understand your point here. I was trying to point out that until
>>>> we do a release we don't know what the version number will be.
>>>> I 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 suggests
>>>> -SNAPSHOT) and then rename it from -SNAPSHOT to 0.3.1 or 0.4 or 1.0 based
>>>> on the version we release. I didn't think changing a version in JIRA was hard.
>>>>
>>>
>>> Changing a version in JIRA is really easy. The 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 have
>> 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. If 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 <zo...@gmail.com> 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<gn...@gmail.com> 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<mn...@apache.org> 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<gn...@gmail.com> 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<gn...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not sure to follow. Right 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 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<no...@apache.org>
>>>>>>>>>>>>> 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<gn...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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: 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
>
--
Alasdair Nottingham
not@apache.org
Re: Please keep JIRA issues up to date
Posted by Andreas Pieber <an...@gmail.com>.
sorry to interrupt but I think the two opinions are clear so far.
a) assume that trunk is always the next non micro and always create support
branches
b) always hack into the trunk and push as required
ok, rough sumup, but still. imho both options are valid, wouldn't it. be
easier to call a vote?
On Feb 18, 2011 2:42 PM, "Guillaume Nodet" <gn...@gmail.com> wrote:
> On Fri, Feb 18, 2011 at 14:05, Alasdair Nottingham <no...@apache.org> wrote:
>> On 18 February 2011 12:22, Guillaume Nodet <gn...@gmail.com> wrote:
>>> On Fri, Feb 18, 2011 at 12:50, Alasdair Nottingham <no...@apache.org>
wrote:
>>>> On 18 February 2011 10:10, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>> On Fri, Feb 18, 2011 at 10:36, Alasdair Nottingham <no...@apache.org>
wrote:
>>>>>>
>>>>>>
>>>>>> Alasdair Nottingham
>>>>>>
>>>>>> On 18 Feb 2011, at 08:59, Guillaume Nodet <gn...@gmail.com> 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 changes.
>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>
>>>> I think trunk should be what we are working on now. Right now to me
that
>>>> 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
>>> http://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
>> do 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... 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
>>>>> ?
>>>>
>>>> I don't understand your point here. I was trying to point out that
until
>>>> we do a release we don't know what the version number will be.
>>>> I 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
suggests
>>>> -SNAPSHOT) and then rename it from -SNAPSHOT to 0.3.1 or 0.4 or 1.0
based
>>>> on the version we release. I didn't think changing a version in JIRA
was hard.
>>>>
>>>
>>> Changing a version in JIRA is really easy. The 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
have
>> 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. If 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 <zo...@gmail.com>
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<gn...@gmail.com>
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<mn...@apache.org>
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<gn...@gmail.com>
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<gnodet@gmail.com
>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not sure to follow. Right 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
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<
not@apache.org>
>>>>>>>>>>>>> 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<gn...@gmail.com>
wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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: 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
Re: Please keep JIRA issues up to date
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Feb 18, 2011 at 14:05, Alasdair Nottingham <no...@apache.org> wrote:
> On 18 February 2011 12:22, Guillaume Nodet <gn...@gmail.com> wrote:
>> On Fri, Feb 18, 2011 at 12:50, Alasdair Nottingham <no...@apache.org> wrote:
>>> On 18 February 2011 10:10, Guillaume Nodet <gn...@gmail.com> wrote:
>>>> On Fri, Feb 18, 2011 at 10:36, Alasdair Nottingham <no...@apache.org> wrote:
>>>>>
>>>>>
>>>>> Alasdair Nottingham
>>>>>
>>>>> On 18 Feb 2011, at 08:59, Guillaume Nodet <gn...@gmail.com> 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 changes.
>>>>>
>>>>>>
>>>>>> 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.
>>>>
>>>
>>> I think trunk should be what we are working on now. Right now to me that
>>> 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
>> http://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
> do 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... 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
>>>> ?
>>>
>>> I don't understand your point here. I was trying to point out that until
>>> we do a release we don't know what the version number will be.
>>> I 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 suggests
>>> -SNAPSHOT) and then rename it from -SNAPSHOT to 0.3.1 or 0.4 or 1.0 based
>>> on the version we release. I didn't think changing a version in JIRA was hard.
>>>
>>
>> Changing a version in JIRA is really easy. The 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 have
> 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. If 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 <zo...@gmail.com> 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<gn...@gmail.com> 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<mn...@apache.org> 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<gn...@gmail.com> 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<gn...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Not sure to follow. Right 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 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<no...@apache.org>
>>>>>>>>>>>> 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<gn...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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: 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
Re: Please keep JIRA issues up to date
Posted by Alasdair Nottingham <no...@apache.org>.
On 18 February 2011 12:22, Guillaume Nodet <gn...@gmail.com> wrote:
> On Fri, Feb 18, 2011 at 12:50, Alasdair Nottingham <no...@apache.org> wrote:
>> On 18 February 2011 10:10, Guillaume Nodet <gn...@gmail.com> wrote:
>>> On Fri, Feb 18, 2011 at 10:36, Alasdair Nottingham <no...@apache.org> wrote:
>>>>
>>>>
>>>> Alasdair Nottingham
>>>>
>>>> On 18 Feb 2011, at 08:59, Guillaume Nodet <gn...@gmail.com> 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 changes.
>>>>
>>>>>
>>>>> 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.
>>>
>>
>> I think trunk should be what we are working on now. Right now to me that
>> 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
> http://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
do 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... 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
>>> ?
>>
>> I don't understand your point here. I was trying to point out that until
>> we do a release we don't know what the version number will be.
>> I 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 suggests
>> -SNAPSHOT) and then rename it from -SNAPSHOT to 0.3.1 or 0.4 or 1.0 based
>> on the version we release. I didn't think changing a version in JIRA was hard.
>>
>
> Changing a version in JIRA is really easy. The 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 have
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. 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.
>
>>>
>>>>
>>>>> On Fri, Feb 18, 2011 at 09:44, zoe slattery <zo...@gmail.com> 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<gn...@gmail.com> 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<mn...@apache.org> 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<gn...@gmail.com> 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<gn...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Not sure to follow. Right 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 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<no...@apache.org>
>>>>>>>>>>> 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<gn...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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: 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
Re: Please keep JIRA issues up to date
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Feb 18, 2011 at 12:50, Alasdair Nottingham <no...@apache.org> wrote:
> On 18 February 2011 10:10, Guillaume Nodet <gn...@gmail.com> wrote:
>> On Fri, Feb 18, 2011 at 10:36, Alasdair Nottingham <no...@apache.org> wrote:
>>>
>>>
>>> Alasdair Nottingham
>>>
>>> On 18 Feb 2011, at 08:59, Guillaume Nodet <gn...@gmail.com> 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 changes.
>>>
>>>>
>>>> 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.
>>
>
> I think trunk should be what we are working on now. Right now to me that
> 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
http://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 ...
>>>>
>>>> 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
>> ?
>
> I don't understand your point here. I was trying to point out that until
> we do a release we don't know what the version number will be.
> I 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 suggests
> -SNAPSHOT) and then rename it from -SNAPSHOT to 0.3.1 or 0.4 or 1.0 based
> on the version we release. I didn't think changing a version in JIRA was hard.
>
Changing a version in JIRA is really easy. The 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 ?
>>
>>>
>>>> On Fri, Feb 18, 2011 at 09:44, zoe slattery <zo...@gmail.com> 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<gn...@gmail.com> 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<mn...@apache.org> 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<gn...@gmail.com> 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<gn...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Not sure to follow. Right 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 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<no...@apache.org>
>>>>>>>>>> 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<gn...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> 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: 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
Re: Please keep JIRA issues up to date
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Feb 18, 2011 at 12:50, Alasdair Nottingham <no...@apache.org> wrote:
> On 18 February 2011 10:10, Guillaume Nodet <gn...@gmail.com> wrote:
>> On Fri, Feb 18, 2011 at 10:36, Alasdair Nottingham <no...@apache.org> wrote:
>>>
>>>
>>> Alasdair Nottingham
>>>
>>> On 18 Feb 2011, at 08:59, Guillaume Nodet <gn...@gmail.com> 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 changes.
>>>
The problem of considering trunk as a maintenance branch until a new
feature comes in is the following: at the time a committer commit a
change that require a minor version bump (2.2 instead of 2.1.1 for
example), the following need to happen:
* create a maintenance branch based on trunk that will be 2.1.1-SNAPSHOT
* move trunk to 2.2-SNAPSHOT
* create a version in jira for 2.2
* mark all issues that have been solved previously in the "2.1.1"
version as being also solved in 2.2 version
I we correctly do the above, using trunk as a maintenance branch for
the last version would work.
If we would go with this model, it means the default trunk would be a
micro version bump and the jira version can be made the same. So we
know what the next version will be. It can later change, but by
default it is a micro update.
The only worry is really that you committer need to really pay
attention to what trunk is so that the above can be done correctly.
>>>>
>>>> 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.
>>
>
> I think trunk should be what we are working on now. Right now to me that
> 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.
>
>>>>
>>>> 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
>> ?
>
> I don't understand your point here. I was trying to point out that until
> we do a release we don't know what the version number will be. I 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 suggests
> -SNAPSHOT) and then rename it from -SNAPSHOT to 0.3.1 or 0.4 or 1.0 based
> on the version we release. I didn't think changing a version in JIRA was hard.
>
>>
>>>
>>>> On Fri, Feb 18, 2011 at 09:44, zoe slattery <zo...@gmail.com> 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<gn...@gmail.com> 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<mn...@apache.org> 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<gn...@gmail.com> 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<gn...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Not sure to follow. Right 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 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<no...@apache.org>
>>>>>>>>>> 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<gn...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> 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: 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
Re: Please keep JIRA issues up to date
Posted by Alasdair Nottingham <no...@apache.org>.
On 18 February 2011 10:10, Guillaume Nodet <gn...@gmail.com> wrote:
> On Fri, Feb 18, 2011 at 10:36, Alasdair Nottingham <no...@apache.org> wrote:
>>
>>
>> Alasdair Nottingham
>>
>> On 18 Feb 2011, at 08:59, Guillaume Nodet <gn...@gmail.com> 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 changes.
>>
>>>
>>> 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.
>
I think trunk should be what we are working on now. Right now to me that
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.
>>>
>>> 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
> ?
I don't understand your point here. I was trying to point out that until
we do a release we don't know what the version number will be. I 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 suggests
-SNAPSHOT) and then rename it from -SNAPSHOT to 0.3.1 or 0.4 or 1.0 based
on the version we release. I didn't think changing a version in JIRA was hard.
>
>>
>>> On Fri, Feb 18, 2011 at 09:44, zoe slattery <zo...@gmail.com> 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<gn...@gmail.com> 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<mn...@apache.org> 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<gn...@gmail.com> 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<gn...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Not sure to follow. Right 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 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<no...@apache.org>
>>>>>>>>> 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<gn...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> 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: 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
Re: Please keep JIRA issues up to date
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Feb 18, 2011 at 10:36, Alasdair Nottingham <no...@apache.org> wrote:
>
>
> Alasdair Nottingham
>
> On 18 Feb 2011, at 08:59, Guillaume Nodet <gn...@gmail.com> 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 changes.
>
>>
>> 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 <zo...@gmail.com> 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<gn...@gmail.com> 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<mn...@apache.org> 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<gn...@gmail.com> 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<gn...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Not sure to follow. Right 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 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<no...@apache.org>
>>>>>>>> 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<gn...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> 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: 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
Re: Please keep JIRA issues up to date
Posted by Alasdair Nottingham <no...@apache.org>.
Alasdair Nottingham
On 18 Feb 2011, at 08:59, Guillaume Nodet <gn...@gmail.com> 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 changes.
>
> 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.
>
> 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.
> On Fri, Feb 18, 2011 at 09:44, zoe slattery <zo...@gmail.com> 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<gn...@gmail.com> 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<mn...@apache.org> 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<gn...@gmail.com> 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<gn...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Not sure to follow. Right 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 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<no...@apache.org>
>>>>>>> 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<gn...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> 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: 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
Re: Please keep JIRA issues up to date
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <zo...@gmail.com> 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<gn...@gmail.com> 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<mn...@apache.org> 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<gn...@gmail.com> 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<gn...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Not sure to follow. Right 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 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<no...@apache.org>
>>>>>> 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<gn...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> 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: 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
Re: Please keep JIRA issues up to date
Posted by zoe slattery <zo...@gmail.com>.
> 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<gn...@gmail.com> 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<mn...@apache.org> 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<gn...@gmail.com> 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<gn...@gmail.com> wrote:
>>>>> Not sure to follow. Right 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 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<no...@apache.org> 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<gn...@gmail.com> wrote:
>>>>>>> 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: 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
>>
>
>
Re: Please keep JIRA issues up to date
Posted by Guillaume Nodet <gn...@gmail.com>.
I think any major compatibility breaking change should be discussed
before committing so that each release doesn't end up in bumping the
major version ... Such changes should be delayed and grouped together
somehow imho, but not sure how often they happen.
On Thu, Feb 17, 2011 at 22:03, Alasdair Nottingham <no...@apache.org> wrote:
> Comments below:
>
> Alasdair Nottingham
>
> On 17 Feb 2011, at 20:10, Guillaume Nodet <gn...@gmail.com> wrote:
>
>> Yes, that would work too. But still, it'd have to be per-bundle anyway.
>>
>
> That is a given.
>
>> Though the problem in doing so, is that we don't know if the next
>> version will be a minor or major bump, which is a really critical
>> information, as you don't really want to change the major version
>> unless there are good reasons for it, and you may want to schedule
>> multiple compatibility breaking changes so that they end up in the
>> same major version.
>
> I don't see how you can know this apriori. Until you do the release you don't know the content, unless we change the way we plan releases. Currently it is on demand, not based on delivered function.
>
>>
>> I we only have "next", when we release, who will decide on the version
>> and what it includes ?
>>
>
> I think that should be discussed on the mailing list at that time.
>
>> On Thu, Feb 17, 2011 at 21:02, Alasdair Nottingham <no...@apache.org> 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?
>>>
>>> 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 <gn...@gmail.com> 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 <mn...@apache.org> 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 <gn...@gmail.com> 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 <gn...@gmail.com> wrote:
>>>>>>> Not sure to follow. Right 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 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 <no...@apache.org> 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 <gn...@gmail.com> wrote:
>>>>>>>>> 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: 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
>>>>
>>>
>>>
>>>
>>> --
>>> 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
Re: Please keep JIRA issues up to date
Posted by Alasdair Nottingham <no...@apache.org>.
Comments below:
Alasdair Nottingham
On 17 Feb 2011, at 20:10, Guillaume Nodet <gn...@gmail.com> wrote:
> Yes, that would work too. But still, it'd have to be per-bundle anyway.
>
That is a given.
> Though the problem in doing so, is that we don't know if the next
> version will be a minor or major bump, which is a really critical
> information, as you don't really want to change the major version
> unless there are good reasons for it, and you may want to schedule
> multiple compatibility breaking changes so that they end up in the
> same major version.
I don't see how you can know this apriori. Until you do the release you don't know the content, unless we change the way we plan releases. Currently it is on demand, not based on delivered function.
>
> I we only have "next", when we release, who will decide on the version
> and what it includes ?
>
I think that should be discussed on the mailing list at that time.
> On Thu, Feb 17, 2011 at 21:02, Alasdair Nottingham <no...@apache.org> 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?
>>
>> 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 <gn...@gmail.com> 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 <mn...@apache.org> 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 <gn...@gmail.com> 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 <gn...@gmail.com> wrote:
>>>>>> Not sure to follow. Right 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 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 <no...@apache.org> 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 <gn...@gmail.com> wrote:
>>>>>>>> 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: 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
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Please keep JIRA issues up to date
Posted by Guillaume Nodet <gn...@gmail.com>.
Yes, that would work too. But still, it'd have to be per-bundle anyway.
Though the problem in doing so, is that we don't know if the next
version will be a minor or major bump, which is a really critical
information, as you don't really want to change the major version
unless there are good reasons for it, and you may want to schedule
multiple compatibility breaking changes so that they end up in the
same major version.
I we only have "next", when we release, who will decide on the version
and what it includes ?
On Thu, Feb 17, 2011 at 21:02, Alasdair Nottingham <no...@apache.org> 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?
>
> 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 <gn...@gmail.com> 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 <mn...@apache.org> 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 <gn...@gmail.com> 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 <gn...@gmail.com> wrote:
>>>>> Not sure to follow. Right 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 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 <no...@apache.org> 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 <gn...@gmail.com> wrote:
>>>>>>> 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: 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
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Please keep JIRA issues up to date
Posted by Alasdair Nottingham <no...@apache.org>.
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?
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 <gn...@gmail.com> 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 <mn...@apache.org> 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 <gn...@gmail.com> 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 <gn...@gmail.com> wrote:
>>>> Not sure to follow. Right 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 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 <no...@apache.org> 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 <gn...@gmail.com> wrote:
>>>>>> 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: 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
>
--
Alasdair Nottingham
not@apache.org
Re: Please keep JIRA issues up to date
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <mn...@apache.org> 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 <gn...@gmail.com> 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 <gn...@gmail.com> wrote:
>>> Not sure to follow. Right 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 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 <no...@apache.org> 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 <gn...@gmail.com> wrote:
>>>>> 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: 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
Re: Please keep JIRA issues up to date
Posted by Mark Nuttall <mn...@apache.org>.
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 <gn...@gmail.com> 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 <gn...@gmail.com> wrote:
>> Not sure to follow. Right 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 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 <no...@apache.org> 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 <gn...@gmail.com> wrote:
>>>> 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: 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
>
Re: Please keep JIRA issues up to date
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <gn...@gmail.com> wrote:
> Not sure to follow. Right 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 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 <no...@apache.org> 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 <gn...@gmail.com> wrote:
>>> 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: 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
Re: Please keep JIRA issues up to date
Posted by Guillaume Nodet <gn...@gmail.com>.
Not sure to follow. Right 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 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 <no...@apache.org> 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 <gn...@gmail.com> wrote:
>> 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: 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
Re: Please keep JIRA issues up to date
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gn...@gmail.com> wrote:
> 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: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org