On Jun 2, 2011, at 5:32 PM, Alasdair Nottingham wrote: > 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.
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
