On 2 June 2011 15:32, Kevan Miller <[email protected]> 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 [email protected]
