On 2 June 2011 19:29, David Jencks <[email protected]> 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 [email protected]
