Hi, Am Donnerstag, den 17.03.2011, 12:08 +0000 schrieb zoe slattery: > Hi > > Hold on: lets first clarify which version of a bundle/module you are > > talking of: > > > > * If it is the bundle/module's own version as specfied along > > with the bundle/module's groupId and artifactId. > > This version is switched to the next SNAPSHOT version by the > > maven release plugin > > --> I strongly suggest to keep this mechanism as is > OK - I had though that it was better to leave the version in trunk being > the same as the release version - but as I work through making the > changes I can see that this will not work. In a perfect world I think it > would be right to do this, but as you suggested I don't think we can > count on people remembering to change the bundle version to > something-SNAPSHOT when they first make a change. I'm having trouble > remembering it as I go along :-)
Right. There is another point to make: Your users would probably be confused to see a release version number of trunk. Release version numbers are generally expected on (immutable) tags while trunk is considered work in progress and should be considered "modified" right from the start. Regards Felix > > * If it is the dependency version of a bundle/module the situation > > is more interesting and is probably what you are refering to. > > > > In the latter (dependency) case you have two situations: > > > > (1) you depend on new exported functionality of the dependency. In this > > case upgrade the dependency when you need the new exported > > functionality. > > > Agreed > > (2) you don't depend on new exported functionality: refer to the lowest > > release version providing enough exported functionality the bundle > > requires. This ensures the import version is automatically set correctly > > to allow for loose coupling supported by OSGi. > Agreed > > Regards > > Felix > > > >> There will be circumstances (maybe the majority?) when a change is made > >> in bundle a which affects no other bundle - I guess it might be hard to > >> remember to change the bundle version in this case. > >> > >> The alternative is, as you suggest, to bump the micro version and add > >> SNAPSHOT after every release. I don't particularly mind this but it > >> gives the release manager the job of checking ALL bundles to see what > >> has changed and could be released, rather than just checking the ones > >> called blah-SNAPSHOT. > >> > >> Zoe > >>> In addition, as I said, the maven release plugin sets the version to > >>> -SNAPSHOT (well, its a default and you can overwrite this in the > >>> release:prepare goal). > >> Yes - you can just override it. And in one sense it's completely > >> reasonable to do so. At the point of release the code in trunk is > >> exactly the same as that which is being released - therefore its version > >> is logically the same. > >>>>> Re. Bundles: I think it is solely the task of the RM to decide on the > >>>>> version to be released. But there should be some guidelines like the > >>>>> OSGi semantic versioning. On point to note (and extending OSGi's paper) > >>>>> is that in Felix and Sling we generally release even versions and have > >>>>> odd versions being SNAPSHOTs. E.g: > >>>>> > >>>>> x.y.1-SNAPSHOT > >>>>> x.y.2 > >>>>> x.y.3-SNAPSHOT > >>>>> x.y.4 > >>>>> > >>>>> The reason for this is that x.y.z.SNAPSHOT> x.y.z in OSGi version > >>>>> speak, which is of course not true in real life (and Maven speak). > >>>> When would this be a problem? If a dependent module (someone else's > >>>> for example) depends on x.y.1 in their<version> element I wouldn't > >>>> expect maven to pick a snapshot. If it did, then a lot of release > >>>> processes would be broken - picking snapshots instead of releases. So > >>>> that makes me think I've misunderstood what you're saying. Can you > >>>> expand a bit? > >>> Its during development and using tools like Sling's JCR Install or OBR. > >>> Remember that OBR obeys OSGi version comparison. > >>> > >>> In fact my proposal stems from early experience we had with OBR in > >>> Apache Sling where bundles were not updated to release versions because > >>> of x.y.z.SNAPSHOT> x.y.z. > >>> > >>> Regards > >>> Felix > >>> > >>>>> FYI: This is how we do it in Sling: > >>>>> http://sling.apache.org/site/version-policy.html. > >>>>> > >>>>> Regards > >>>>> Felix > >>>>> > >>>>> Am Mittwoch, den 16.03.2011, 09:20 +0000 schrieb zoe slattery: > >>>>>> Hi - as I work through making the changes to be able to release by > >>>>>> bundle we will need to start following an agreed version policy for > >>>>>> packages and bundles. > >>>>>> I've drafted something on the wiki (website). Please review it and > >>>>>> comment back to the list. > >>>>>> > >>>>>> http://aries.apache.org/development/versionpolicy.html > >>>>>> > >>>>>> Thanks, Zoë > >>>>> > >>> > > > > >
