You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by David Jencks <da...@yahoo.com> on 2011/06/01 04:16:33 UTC
Re: internal version conflict in aries application (at least)
On May 30, 2011, at 10:21 AM, zoe slattery wrote:
>
>>> This branch development version is incorrect because of the switch of release scheme. In switching release scheme one assumption was that nothing would ever be released from the 0.3 branch again so maybe it ought to be deleted? Any future releases will always be from trunk.
>> That may not be a safe assumption. Geronimo would like to get a release out pretty soon and there is little evidence at the moment that trunk will be stable enough to be usable. On the other hand 0.3 also has its share of blocking bugs.
> Releasing from the 0.3 branch has some implications for Aries release management - I suspect that it has the potential to create a lot of work so I would encourage you to use what is in trunk if you possibly can.
I'd like to figure out an appropriate version number for the 0.3 branch and change to it. It would be great to get trunk released but every time I turn around I find another problem apparently with the weaving/proxying code and I'm not confident we can find and fix all the problems quickly enough.
Locally I made a 0.3.0.1-SNAPSHOT application branch that appeared to work fine with geronimo. What do you expect to be a problem with changing the versions in 0.3-RCx to 0.3.0.1-SNAPSHOT?
thanks
david jencks
>
> Zoe
>>
>
Re: internal version conflict in aries application (at least)
Posted by Alasdair Nottingham <no...@apache.org>.
On 2 June 2011 19:29, David Jencks <da...@yahoo.com> wrote:
> I am moderately hopeful that geronimo can use trunk however....
>
> What I don't understand in this discussion is why a bug fix release to a pre-semantic-versioning-decision release needs to have semantic versioning. IIUC trunk has incremented at least the 3rd digit on every bundle version and the bug fix would increment the 4th digit.... maybe not completely correct but OK for me.
We have to start somewhere. I think it will be confusing in some
"0.3.x" bundles are semantically versioned from the 0.3 release and
others are not. So if we were to say "ok lets do releases in 0.3 that
are not semantically versioned" would that mean we move everything up
to 0.4 and start from there? Then do we get similar pressure to allow
0.4 non-semanticly versioned changes. The change has to occur sometime
and we had decided it was with the 0.3 release.
>
> If this is going to cause problems then I think there was an important factor left out of the semantic versioning discussion and I'd suggest that despite compatibility issues you need to increment the first or second digit of all the trunk versions to allow room for bug fixes on 0.3. EIther that or rerelease the 0.3 code as-is with the semantic versioning scheme with whatever numbers are correct so as to allow for bug fixes.
Personally I hope that when we do a 1.0 release of something it is
because the API is stable and we pass all relevant OSGi CTs. This
isn't the case for a lot right now so a major upgrade would be bad. A
minor could be made, but then we are, in my view, just postponing the
"issue" and some precedent can always be claimed to not follow the new
release process. Since aries is promoting a programming model for
enterprise OSGi I think we need to practice the rules we want apps to
follow.
>
> reading the http://aries.apache.org/development/versionpolicy.htm there's an obvious problem with bug fix releases if the trunk maven version is only updated on release. This may be what we're running into.
Yeah, In fact we haven't really followed this. Several modules have
gone to 0.4 because we know we have made API changes. I'm in favour of
doing it when you make the change and then having the release manager
validate we didn't do it twice. For instance an API package recently
was upped accidentally to 0.5 despite the last release version being
0.4.
>
> Consider a bundle released at bundle version 0.3.0. The maven version of trunk will then be 0.3.1-SNAPSHOT. Suppose development proceeds on trunk and a method is added to an exported interface so the package version is 0.4.0. Now a bug fix branch is created from the 0.3.0 release tag. It's going to get released at bundle version 0.3.1. What should its maven version be? I'd say 0.3.1-SNAPSHOT is pretty much the only plausible version. In any case after its released it is ridiculous to have trunk at 0.3.1-SNAPSHOT after 0.3.1 is released, this would cause a lot of maven problems.
I don't think that is the right flow. I think the right flow would be
you do work in trunk. You then need a 0.3.1 release, assuming trunk
hasn't broken APIs we release it as 0.3.1 and it moves to 0.3.2. This
works fine. At some point an API or breaking change is made and trunk
goes to 0.4. Then someone needs a bug fix. At that point we go to the
0.3.1 tag and create a branch from it, add the bug fixes and we
release from there. This way we never have 0.3.1 in a service branch
and trunk. We also only have a branch when we actually need the
release, we don't create one "just in case".
>
> BTW there are a few places in that doc where -SNAPSHOT is left off such as....
>
> For example, if proxy is released at version 1.0.0, the development version of proxy in trunk will become 1.0.1.
I don't know if I understand these last two points, but it might be
because they are related to the previous one I just addressed. Sending
emails at 10pm probably isn't the best idea.
Alasdair
>
> thanks
> david jencks
>
> On Jun 2, 2011, at 10:51 AM, zoe slattery wrote:
>
>>
>>> OK. So, apologies for hashing/re-hashing the subject... And yes, I'm negligent of not paying close attention to the various discussions. But that doesn't mean we can't be discussing now... If a 0.3.0 cannot be generated, then so be it... Just help us understand why...
>>
>> Changing to use OSGi semantic versioning was complex and the subject of much discussion on the list. I did most of Maven work to make it happen so I'm probably best placed to explain, but even so it's complex. If you want to understand the rationale Alasdair gave a set of links to earlier discussions, however a better place to start (where we started in fact) was to read the OSGi alliance white paper www.*osgi*.org/wiki/uploads/Links/*SemanticVersioning*.pdf. There is an important paragraph towards the end where bundle versions are discussed.
>>
>> Each bundle is now released separately as it must be if each bundle is to be versioned separately. In the past we used a release by module scheme but the maven release plugin will not handle having independently versioned submodules - so we had to abandon this way of working.
>>
>> At release time the version of each bundle is determined by comparing it (in particular changes to packages) with the last released version. So - a bundle being developed at say, 0.3.1-SNAPSHOT might well get released at 0.3.1 or 0.4.0 depending on what had changed since the last release. This is all documented on the web pages http://aries.apache.org/development/versionpolicy.html.
>>
>> There are aspects of the scheme that we implemented that none of us like, we spent a long time trying to improve on it. But, in the end we are an OSGi project and implementing OSGi properly was more important to us than a simple release scheme.
>>
>> If you want to find some way to release from 0.3 and honour the OSGi versioning policy that we implemented ... it might be possible. I can't think how and given that it took (iirc) between 4 and 6 weeks of my time to switch us to semantic versioning I think you would be better to take code from trunk because I think it will take less time.
>>
>> Zoe
>>
>>
>>> --kevan
>>
>
>
--
Alasdair Nottingham
not@apache.org
Re: internal version conflict in aries application (at least)
Posted by David Jencks <da...@yahoo.com>.
I am moderately hopeful that geronimo can use trunk however....
What I don't understand in this discussion is why a bug fix release to a pre-semantic-versioning-decision release needs to have semantic versioning. IIUC trunk has incremented at least the 3rd digit on every bundle version and the bug fix would increment the 4th digit.... maybe not completely correct but OK for me.
If this is going to cause problems then I think there was an important factor left out of the semantic versioning discussion and I'd suggest that despite compatibility issues you need to increment the first or second digit of all the trunk versions to allow room for bug fixes on 0.3. EIther that or rerelease the 0.3 code as-is with the semantic versioning scheme with whatever numbers are correct so as to allow for bug fixes.
reading the http://aries.apache.org/development/versionpolicy.htm there's an obvious problem with bug fix releases if the trunk maven version is only updated on release. This may be what we're running into.
Consider a bundle released at bundle version 0.3.0. The maven version of trunk will then be 0.3.1-SNAPSHOT. Suppose development proceeds on trunk and a method is added to an exported interface so the package version is 0.4.0. Now a bug fix branch is created from the 0.3.0 release tag. It's going to get released at bundle version 0.3.1. What should its maven version be? I'd say 0.3.1-SNAPSHOT is pretty much the only plausible version. In any case after its released it is ridiculous to have trunk at 0.3.1-SNAPSHOT after 0.3.1 is released, this would cause a lot of maven problems.
BTW there are a few places in that doc where -SNAPSHOT is left off such as....
For example, if proxy is released at version 1.0.0, the development version of proxy in trunk will become 1.0.1.
thanks
david jencks
On Jun 2, 2011, at 10:51 AM, zoe slattery wrote:
>
>> OK. So, apologies for hashing/re-hashing the subject... And yes, I'm negligent of not paying close attention to the various discussions. But that doesn't mean we can't be discussing now... If a 0.3.0 cannot be generated, then so be it... Just help us understand why...
>
> Changing to use OSGi semantic versioning was complex and the subject of much discussion on the list. I did most of Maven work to make it happen so I'm probably best placed to explain, but even so it's complex. If you want to understand the rationale Alasdair gave a set of links to earlier discussions, however a better place to start (where we started in fact) was to read the OSGi alliance white paper www.*osgi*.org/wiki/uploads/Links/*SemanticVersioning*.pdf. There is an important paragraph towards the end where bundle versions are discussed.
>
> Each bundle is now released separately as it must be if each bundle is to be versioned separately. In the past we used a release by module scheme but the maven release plugin will not handle having independently versioned submodules - so we had to abandon this way of working.
>
> At release time the version of each bundle is determined by comparing it (in particular changes to packages) with the last released version. So - a bundle being developed at say, 0.3.1-SNAPSHOT might well get released at 0.3.1 or 0.4.0 depending on what had changed since the last release. This is all documented on the web pages http://aries.apache.org/development/versionpolicy.html.
>
> There are aspects of the scheme that we implemented that none of us like, we spent a long time trying to improve on it. But, in the end we are an OSGi project and implementing OSGi properly was more important to us than a simple release scheme.
>
> If you want to find some way to release from 0.3 and honour the OSGi versioning policy that we implemented ... it might be possible. I can't think how and given that it took (iirc) between 4 and 6 weeks of my time to switch us to semantic versioning I think you would be better to take code from trunk because I think it will take less time.
>
> Zoe
>
>
>> --kevan
>
Re: internal version conflict in aries application (at least)
Posted by zoe slattery <zo...@gmail.com>.
> OK. So, apologies for hashing/re-hashing the subject... And yes, I'm negligent of not paying close attention to the various discussions. But that doesn't mean we can't be discussing now... If a 0.3.0 cannot be generated, then so be it... Just help us understand why...
Changing to use OSGi semantic versioning was complex and the subject of
much discussion on the list. I did most of Maven work to make it happen
so I'm probably best placed to explain, but even so it's complex. If you
want to understand the rationale Alasdair gave a set of links to earlier
discussions, however a better place to start (where we started in fact)
was to read the OSGi alliance white paper
www.*osgi*.org/wiki/uploads/Links/*SemanticVersioning*.pdf. There is an
important paragraph towards the end where bundle versions are discussed.
Each bundle is now released separately as it must be if each bundle is
to be versioned separately. In the past we used a release by module
scheme but the maven release plugin will not handle having independently
versioned submodules - so we had to abandon this way of working.
At release time the version of each bundle is determined by comparing it
(in particular changes to packages) with the last released version. So -
a bundle being developed at say, 0.3.1-SNAPSHOT might well get released
at 0.3.1 or 0.4.0 depending on what had changed since the last release.
This is all documented on the web pages
http://aries.apache.org/development/versionpolicy.html.
There are aspects of the scheme that we implemented that none of us
like, we spent a long time trying to improve on it. But, in the end we
are an OSGi project and implementing OSGi properly was more important to
us than a simple release scheme.
If you want to find some way to release from 0.3 and honour the OSGi
versioning policy that we implemented ... it might be possible. I can't
think how and given that it took (iirc) between 4 and 6 weeks of my time
to switch us to semantic versioning I think you would be better to take
code from trunk because I think it will take less time.
Zoe
> --kevan
Re: internal version conflict in aries application (at least)
Posted by Kevan Miller <ke...@gmail.com>.
On Jun 2, 2011, at 5:32 PM, Alasdair Nottingham wrote:
> On 2 June 2011 15:32, Kevan Miller <ke...@gmail.com> wrote:
>>
>> On Jun 2, 2011, at 5:55 AM, Alasdair Nottingham wrote:
>>
>>> Hi,
>>>
>>> I would like to echo Zoe's comments. I know you are hitting problems
>>> in trunk, but I think we need to identify the exact list of problems
>>> and address them in trunk rather than the defunct 0.3 branch which
>>> should really be deleted.
>>>
>>> The problem with using a 0.3.0.1-SNAPSHOT in the 0.3 branch is that
>>> the OSGi semantic versions use a major.minor.micro.qualifier model. In
>>> this model 0.3.0 is versioned according to numerical progression, and
>>> 1-SNAPSHOT is a String.compareTo. The ordering would be fine until we
>>> wanted a 0.3.0.10-SNAPSHOT at which point, I think 0.3.0.10-SNAPSHOT
>>> would be treated as less than 0.3.0.2-SNAPSHOT which is not what we
>>> want.
>>
>> A few comments:
>>
>> Tim, in response to your earlier email -- I don't think there would be any complaints about your fixes (or the speed of your fixes). Or, for that matter, anyone else's code in trunk. I expect there to be issues like this on a development *trunk*. So, no worries about any issues that are being uncovered...
>>
>> Except, the issue is that we're forced to pick up fixes on a development *trunk*... We found a problem with 0.3.0. The fix is relatively minor. Instead of being able to fix the problem on a stable "branch", we're forced to pick up a lot of new code on a development "trunk". It introduces instabilities that we don't need and probably puts us on a release schedule that is further out than we might desire.
>
> I'm sorry, but I think it would make sense, on a separate thread, to
> discuss the exact issues you have, both with 0.3.0 and with trunk. It
> is completely opaque to me, and I suspect to other people, since I
> haven't seen any thread that iterates problems other than the proxy
> bugs which don't affect 0.3.0. Rather than have statements about
> trunk being unstable and minor bugs in stable branches I would like to
> know specifics. This will help me, and I expect others, to understand
> a little better your perspective.
OK. So, then it would seem we're largely in agreement. It depends on the technical requirements of the situation. Not some dogma.
>
> It is also worth pointing out that I put a lot of fixes into the
> application module post the 0.3.0 release which I would be surprised
> if you didn't need.
Maybe. Hadn't noticed the need for them, so far... ;-)
>
>>
>> If I understand correctly, your major reason for this restriction is that after 9 more micro releases, we're going to have a version ordering problem? So, we shouldn't have any micro releases at all?
>
> Err, I'm not sure what to say here. I'm pointing out that the scheme
> proposed has a very limited shelf life. If you read my email I
> describe the third digit as micro so clearly I am not suggesting we
> can't have micro releases. I'm saying that we shouldn't do releases
> where the only place the version change is communicated in is the
> qualifier. In my opinion the qualifier is used to identify different
> builds of the same thing, or in maven parlance to differentiate a
> newer snapshot from an older one.
OK. Thanks for the explanation. I did misread the intent of your statement...
>
>>
>>>
>>> As Zoe said we had a long discussion and a vote regarding this issue.
>>> The discussions are archived and below are some links that hook into
>>> the archive of the discussions and the final vote:
>>
>> OK. So, apologies for hashing/re-hashing the subject... And yes, I'm negligent of not paying close attention to the various discussions. But that doesn't mean we can't be discussing now... If a 0.3.0 cannot be generated, then so be it... Just help us understand why...
>
> I think you may be reading something into what I said that I neither
> said, nor meant to say. My reason for providing the information was so
> David, and although I did not know it at the time you, could more
> easily access the original discussion to gain more of an understanding
> of why we changed. Since I was involved I thought it would be easier
> for me to hunt the info out of the archive for you, than to leave it
> to you and David to do yourself with no context or timeframe. If you
> think this was the wrong, and unhelpful, then I am truly sorry and
> will refrain from doing so in the future.
I misread the intent of your qualifier example...
--kevan
Re: internal version conflict in aries application (at least)
Posted by Alasdair Nottingham <no...@apache.org>.
On 2 June 2011 15:32, Kevan Miller <ke...@gmail.com> wrote:
>
> On Jun 2, 2011, at 5:55 AM, Alasdair Nottingham wrote:
>
>> Hi,
>>
>> I would like to echo Zoe's comments. I know you are hitting problems
>> in trunk, but I think we need to identify the exact list of problems
>> and address them in trunk rather than the defunct 0.3 branch which
>> should really be deleted.
>>
>> The problem with using a 0.3.0.1-SNAPSHOT in the 0.3 branch is that
>> the OSGi semantic versions use a major.minor.micro.qualifier model. In
>> this model 0.3.0 is versioned according to numerical progression, and
>> 1-SNAPSHOT is a String.compareTo. The ordering would be fine until we
>> wanted a 0.3.0.10-SNAPSHOT at which point, I think 0.3.0.10-SNAPSHOT
>> would be treated as less than 0.3.0.2-SNAPSHOT which is not what we
>> want.
>
> A few comments:
>
> Tim, in response to your earlier email -- I don't think there would be any complaints about your fixes (or the speed of your fixes). Or, for that matter, anyone else's code in trunk. I expect there to be issues like this on a development *trunk*. So, no worries about any issues that are being uncovered...
>
> Except, the issue is that we're forced to pick up fixes on a development *trunk*... We found a problem with 0.3.0. The fix is relatively minor. Instead of being able to fix the problem on a stable "branch", we're forced to pick up a lot of new code on a development "trunk". It introduces instabilities that we don't need and probably puts us on a release schedule that is further out than we might desire.
I'm sorry, but I think it would make sense, on a separate thread, to
discuss the exact issues you have, both with 0.3.0 and with trunk. It
is completely opaque to me, and I suspect to other people, since I
haven't seen any thread that iterates problems other than the proxy
bugs which don't affect 0.3.0. Rather than have statements about
trunk being unstable and minor bugs in stable branches I would like to
know specifics. This will help me, and I expect others, to understand
a little better your perspective.
It is also worth pointing out that I put a lot of fixes into the
application module post the 0.3.0 release which I would be surprised
if you didn't need.
>
> If I understand correctly, your major reason for this restriction is that after 9 more micro releases, we're going to have a version ordering problem? So, we shouldn't have any micro releases at all?
Err, I'm not sure what to say here. I'm pointing out that the scheme
proposed has a very limited shelf life. If you read my email I
describe the third digit as micro so clearly I am not suggesting we
can't have micro releases. I'm saying that we shouldn't do releases
where the only place the version change is communicated in is the
qualifier. In my opinion the qualifier is used to identify different
builds of the same thing, or in maven parlance to differentiate a
newer snapshot from an older one.
>
>>
>> As Zoe said we had a long discussion and a vote regarding this issue.
>> The discussions are archived and below are some links that hook into
>> the archive of the discussions and the final vote:
>
> OK. So, apologies for hashing/re-hashing the subject... And yes, I'm negligent of not paying close attention to the various discussions. But that doesn't mean we can't be discussing now... If a 0.3.0 cannot be generated, then so be it... Just help us understand why...
I think you may be reading something into what I said that I neither
said, nor meant to say. My reason for providing the information was so
David, and although I did not know it at the time you, could more
easily access the original discussion to gain more of an understanding
of why we changed. Since I was involved I thought it would be easier
for me to hunt the info out of the archive for you, than to leave it
to you and David to do yourself with no context or timeframe. If you
think this was the wrong, and unhelpful, then I am truly sorry and
will refrain from doing so in the future.
>
> --kevan
--
Alasdair Nottingham
not@apache.org
Re: internal version conflict in aries application (at least)
Posted by Kevan Miller <ke...@gmail.com>.
On Jun 2, 2011, at 5:55 AM, Alasdair Nottingham wrote:
> Hi,
>
> I would like to echo Zoe's comments. I know you are hitting problems
> in trunk, but I think we need to identify the exact list of problems
> and address them in trunk rather than the defunct 0.3 branch which
> should really be deleted.
>
> The problem with using a 0.3.0.1-SNAPSHOT in the 0.3 branch is that
> the OSGi semantic versions use a major.minor.micro.qualifier model. In
> this model 0.3.0 is versioned according to numerical progression, and
> 1-SNAPSHOT is a String.compareTo. The ordering would be fine until we
> wanted a 0.3.0.10-SNAPSHOT at which point, I think 0.3.0.10-SNAPSHOT
> would be treated as less than 0.3.0.2-SNAPSHOT which is not what we
> want.
A few comments:
Tim, in response to your earlier email -- I don't think there would be any complaints about your fixes (or the speed of your fixes). Or, for that matter, anyone else's code in trunk. I expect there to be issues like this on a development *trunk*. So, no worries about any issues that are being uncovered...
Except, the issue is that we're forced to pick up fixes on a development *trunk*... We found a problem with 0.3.0. The fix is relatively minor. Instead of being able to fix the problem on a stable "branch", we're forced to pick up a lot of new code on a development "trunk". It introduces instabilities that we don't need and probably puts us on a release schedule that is further out than we might desire.
If I understand correctly, your major reason for this restriction is that after 9 more micro releases, we're going to have a version ordering problem? So, we shouldn't have any micro releases at all?
>
> As Zoe said we had a long discussion and a vote regarding this issue.
> The discussions are archived and below are some links that hook into
> the archive of the discussions and the final vote:
OK. So, apologies for hashing/re-hashing the subject... And yes, I'm negligent of not paying close attention to the various discussions. But that doesn't mean we can't be discussing now... If a 0.3.0 cannot be generated, then so be it... Just help us understand why...
--kevan
Re: internal version conflict in aries application (at least)
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
I would like to echo Zoe's comments. I know you are hitting problems
in trunk, but I think we need to identify the exact list of problems
and address them in trunk rather than the defunct 0.3 branch which
should really be deleted.
The problem with using a 0.3.0.1-SNAPSHOT in the 0.3 branch is that
the OSGi semantic versions use a major.minor.micro.qualifier model. In
this model 0.3.0 is versioned according to numerical progression, and
1-SNAPSHOT is a String.compareTo. The ordering would be fine until we
wanted a 0.3.0.10-SNAPSHOT at which point, I think 0.3.0.10-SNAPSHOT
would be treated as less than 0.3.0.2-SNAPSHOT which is not what we
want.
As Zoe said we had a long discussion and a vote regarding this issue.
The discussions are archived and below are some links that hook into
the archive of the discussions and the final vote:
http://mail-archives.apache.org/mod_mbox/aries-dev/201101.mbox/%3c4D469A67.1060800@gmail.com%3e
http://mail-archives.apache.org/mod_mbox/aries-dev/201102.mbox/%3cAANLkTinD3GVJrKcQ1Fz6BAQFwEvrCCLobYJPWF5G4SJ_@mail.gmail.com%3e
http://mail-archives.apache.org/mod_mbox/aries-dev/201102.mbox/%3cAANLkTi=XkJ3+ED7o_89PWVaC1drPJQwS9a8FxOcQJcR9@mail.gmail.com%3e
http://mail-archives.apache.org/mod_mbox/aries-dev/201102.mbox/%3c4D4817DA.90201@gmail.com%3e
http://mail-archives.apache.org/mod_mbox/aries-dev/201102.mbox/%3cAANLkTinGk6EN2k9Ru+-S-=0syXkmBnE05xhMLP3-CM4N@mail.gmail.com%3e
http://mail-archives.apache.org/mod_mbox/aries-dev/201102.mbox/%3cAANLkTimOF2a+JywfF_8yti1H6EvfOXMLMksjP+5OSqV+@mail.gmail.com%3e
http://mail-archives.apache.org/mod_mbox/aries-dev/201102.mbox/%3cAANLkTin6MzsVfK4JpS0WYKj9HTE8yVar7PetvsTX7OPh@mail.gmail.com%3e
http://mail-archives.apache.org/mod_mbox/aries-dev/201102.mbox/%3c4D4C4A71.1080303@gmail.com%3e
http://mail-archives.apache.org/mod_mbox/aries-dev/201102.mbox/%3c4D500247.1080207@gmail.com%3e
This is the discuss thread:
http://mail-archives.apache.org/mod_mbox/aries-dev/201102.mbox/%3c4D52CFCE.3090205@gmail.com%3e
and a summary: http://mail-archives.apache.org/mod_mbox/aries-dev/201102.mbox/%3c4D57E73D.5060903@gmail.com%3e
http://mail-archives.apache.org/mod_mbox/aries-dev/201102.mbox/%3c4D6B88B6.9080102@gmail.com%3e
http://mail-archives.apache.org/mod_mbox/aries-dev/201103.mbox/%3cAANLkTimjZ7P48iLvRsdJxVUUgs+7q3oM4k88pa35zJq+@mail.gmail.com%3e
This is the vote thread:
http://mail-archives.apache.org/mod_mbox/aries-dev/201103.mbox/%3c4D6E5B46.1000202@gmail.com%3e
This is the vote result thread:
http://mail-archives.apache.org/mod_mbox/aries-dev/201103.mbox/%3c4D74A869.5010602@gmail.com%3e
Alasdair
On 2 June 2011 10:12, zoe slattery <zo...@gmail.com> wrote:
> On 01/06/2011 03:16, David Jencks wrote:
>>
>> On May 30, 2011, at 10:21 AM, zoe slattery wrote:
>>
>>>>> This branch development version is incorrect because of the switch of
>>>>> release scheme. In switching release scheme one assumption was that nothing
>>>>> would ever be released from the 0.3 branch again so maybe it ought to be
>>>>> deleted? Any future releases will always be from trunk.
>>>>
>>>> That may not be a safe assumption. Geronimo would like to get a release
>>>> out pretty soon and there is little evidence at the moment that trunk will
>>>> be stable enough to be usable. On the other hand 0.3 also has its share of
>>>> blocking bugs.
>>>
>>> Releasing from the 0.3 branch has some implications for Aries release
>>> management - I suspect that it has the potential to create a lot of work so
>>> I would encourage you to use what is in trunk if you possibly can.
>>
>> I'd like to figure out an appropriate version number for the 0.3 branch
>> and change to it. It would be great to get trunk released but every time I
>> turn around I find another problem apparently with the weaving/proxying code
>> and I'm not confident we can find and fix all the problems quickly enough.
>>
>> Locally I made a 0.3.0.1-SNAPSHOT application branch that appeared to work
>> fine with geronimo. What do you expect to be a problem with changing the
>> versions in 0.3-RCx to 0.3.0.1-SNAPSHOT?
>
> I think there are several issues here. The thing that concerns me most is
> that some months ago we had a lengthy discussion on this list about whether
> we should move to a release by bundle process and implement OSGi semantic
> versioning correctly. This discussion ended in a vote and we agreed to move
> forward and modify our development and release process to implement OSGi
> semantic versioning. If you want a release from the 0.3 branch you are
> overturning something that we voted on agreed.
>
> As far as development versions go I don't think what you call the versions
> in the 0.3 branch matters a lot. So, as long as you never release from it I
> don't really see an issue (although I may well have missed something). If
> you ever want a release from that branch someone will need to work through
> and figure out how to align what you want with the OSGi semantic versioning
> scheme that we set up. I don't think this is a trivial task, so that, and
> the belief that there are significant enhancements in trunk that would
> benefit Geronimo, is why I am strongly encouraging you to use trunk.
>
> Zoe
>>
>> thanks
>> david jencks
>>
>>> Zoe
>>
>
>
--
Alasdair Nottingham
not@apache.org
Re: internal version conflict in aries application (at least)
Posted by zoe slattery <zo...@gmail.com>.
On 01/06/2011 03:16, David Jencks wrote:
> On May 30, 2011, at 10:21 AM, zoe slattery wrote:
>
>>>> This branch development version is incorrect because of the switch of release scheme. In switching release scheme one assumption was that nothing would ever be released from the 0.3 branch again so maybe it ought to be deleted? Any future releases will always be from trunk.
>>> That may not be a safe assumption. Geronimo would like to get a release out pretty soon and there is little evidence at the moment that trunk will be stable enough to be usable. On the other hand 0.3 also has its share of blocking bugs.
>> Releasing from the 0.3 branch has some implications for Aries release management - I suspect that it has the potential to create a lot of work so I would encourage you to use what is in trunk if you possibly can.
> I'd like to figure out an appropriate version number for the 0.3 branch and change to it. It would be great to get trunk released but every time I turn around I find another problem apparently with the weaving/proxying code and I'm not confident we can find and fix all the problems quickly enough.
>
> Locally I made a 0.3.0.1-SNAPSHOT application branch that appeared to work fine with geronimo. What do you expect to be a problem with changing the versions in 0.3-RCx to 0.3.0.1-SNAPSHOT?
I think there are several issues here. The thing that concerns me most
is that some months ago we had a lengthy discussion on this list about
whether we should move to a release by bundle process and implement OSGi
semantic versioning correctly. This discussion ended in a vote and we
agreed to move forward and modify our development and release process to
implement OSGi semantic versioning. If you want a release from the 0.3
branch you are overturning something that we voted on agreed.
As far as development versions go I don't think what you call the
versions in the 0.3 branch matters a lot. So, as long as you never
release from it I don't really see an issue (although I may well have
missed something). If you ever want a release from that branch someone
will need to work through and figure out how to align what you want with
the OSGi semantic versioning scheme that we set up. I don't think this
is a trivial task, so that, and the belief that there are significant
enhancements in trunk that would benefit Geronimo, is why I am strongly
encouraging you to use trunk.
Zoe
> thanks
> david jencks
>
>> Zoe
>
RE: internal version conflict in aries application (at least)
Posted by Timothy Ward <ti...@apache.org>.
Hi,
I'm sorry if you don't feel that the problems you've had with proxy are being addressed fast enough, my understanding was that things were, for the most part, working now. Clearly there is a JCDI bug related to synthetic methods, however I have suggested a 1 line work-around in the proxy code for that. There is also a patch on the dev list that should reduce the additional memory overhead you noticed.
Is there more that I'm unaware of? Are there other test cases failing?
Regards,
Tim
----------------------------------------
> Subject: Re: internal version conflict in aries application (at least)
> From: david_jencks@yahoo.com
> Date: Tue, 31 May 2011 19:16:33 -0700
> To: dev@aries.apache.org
>
>
> On May 30, 2011, at 10:21 AM, zoe slattery wrote:
>
> >
> >>> This branch development version is incorrect because of the switch of release scheme. In switching release scheme one assumption was that nothing would ever be released from the 0.3 branch again so maybe it ought to be deleted? Any future releases will always be from trunk.
> >> That may not be a safe assumption. Geronimo would like to get a release out pretty soon and there is little evidence at the moment that trunk will be stable enough to be usable. On the other hand 0.3 also has its share of blocking bugs.
> > Releasing from the 0.3 branch has some implications for Aries release management - I suspect that it has the potential to create a lot of work so I would encourage you to use what is in trunk if you possibly can.
>
> I'd like to figure out an appropriate version number for the 0.3 branch and change to it. It would be great to get trunk released but every time I turn around I find another problem apparently with the weaving/proxying code and I'm not confident we can find and fix all the problems quickly enough.
>
> Locally I made a 0.3.0.1-SNAPSHOT application branch that appeared to work fine with geronimo. What do you expect to be a problem with changing the versions in 0.3-RCx to 0.3.0.1-SNAPSHOT?
>
> thanks
> david jencks
>
> >
> > Zoe
> >>
> >
>