aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <>
Subject Re: internal version conflict in aries application (at least)
Date Thu, 02 Jun 2011 21:32:50 GMT
On 2 June 2011 15:32, Kevan Miller <> 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 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 at which point, I think
>> would be treated as less than 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

View raw message