Hi David, For an interface, the tool just finds out whether it has binary compatibility changes or not. If yes, the major version will need to be updated. If it has new methods etc (based on sementic versioning white paper), its minor version needs to be increased. Its version should be determined by the changes not by the different types of clients. As mentioned by Valentin, its client or implementors can protect themselves by using different version ranges.
By the way, the tool is implemented based on the semantic version white paper as per your email. Regards Emily On Thu, Sep 29, 2011 at 9:05 AM, David Bosschaert < [email protected]> wrote: > Hi Valentin, > > It's all in this doc: > www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf > > Cheers, > > David > > On 29 September 2011 08:34, Valentin Mahrwald <[email protected]> > wrote: > > Hm, I thought the distinction between usage of the interface was a > distinction made on the import side. So as for an interface I am using but > not implementing I have a range of [a, a+1) and for one I am using through > implementation, [a, a+0.1). In either case I would have thought the semantic > versioning tool should suggest a+0.1 as the next version for adding a new > method, so as to enable the user to make that choice. > > > > What am I missing? > > > > Regards, > > > > Valentin > > > > On 29 Sep 2011, at 08:28, David Bosschaert wrote: > > > >> Hi Emily, > >> > >> Yes, sounds great. Especially if this plugin can ultimately be > >> integrated with maven and work alongside the maven-bundle-plugin that > >> would be great. > >> > >> Regarding the semantic versioning, this relates to the role that a > >> certain interface plays. > >> If an interface is extended (e.g. with a new method) then there are > >> two situations: > >> * if it's an interface that is supposed to be *implemented* by end > >> users then this is a major version increase. I think this is what you > >> have right now. > >> * however, if it's an interface that is supposed to be *used* by end > >> users but implemented by the infrastructure (e.g. part of the > >> 'project' you are comparing, which might span multiple bundles) then > >> only a minor version increase is needed. In this case the interface is > >> still binary compatible with users of it. It's just not compatible > >> with implementors of it. Note that this only applies to a limited set > >> of changes to an interface. E.g. removing a method is binary > >> incompatible for everyone. > >> > >> I'm not sure whether its possible to automatically guess what the role > >> of an interface is, so the tool needs to be configurable wrt to this. > >> I would even suggest that the tool fails unless this information is > >> available for all its public interfaces since guessing it wrong can > >> have pretty bad consequences. > >> > >> Cheers, > >> > >> David > >> > >> On 28 September 2011 19:36, Alasdair Nottingham <[email protected]> wrote: > >>> +1 > >>> > >>> I think this would be a really good tool to have here. I'm happy to > assist > >>> with getting it integrated if you need anything. > >>> > >>> Thanks > >>> Alasdair > >>> > >>> On 28 September 2011 17:17, Emily Jiang <[email protected]> > wrote: > >>> > >>>> I use ASM and also have to load classes to access super classes:(. > >>>> > >>>> On Wed, Sep 28, 2011 at 5:10 PM, Timothy Ward < > [email protected] > >>>>> wrote: > >>>> > >>>>> > >>>>> Emily, > >>>>> > >>>>> Are you using ASM, or some other bytecode tool, to work out what has > >>>>> changed, or do you have to load classes and use reflection to find > out? > >>>>> > >>>>> Regards, > >>>>> > >>>>> Tim > >>>>> > >>>>>> Date: Wed, 28 Sep 2011 16:58:33 +0100 > >>>>>> Subject: Re: Semantic Versioning tool > >>>>>> From: [email protected] > >>>>>> To: [email protected] > >>>>>> > >>>>>> Hi David, > >>>>>> > >>>>>> It works by comparing the current binary with the baseline binary: > >>>>>> 1. For each export package, it scans each non private class to see > >>>>> whether > >>>>>> there are binary incompatibility changes (according to Java > >>>>> specificiation > >>>>>> chapter 13 Binary Compability). If yes, a major version change is > >>>> needed > >>>>> for > >>>>>> this pkg. > >>>>>> 2. If there are not binary incompability changes, it will see > whether > >>>>> there > >>>>>> are abstract class, methods or new xsd file added. If yes, the > >>>> package's > >>>>>> minor version needs to be increased. > >>>>>> 3. It then determine the bundle version based on package versions > >>>> changed > >>>>>> according to semantic versioning white paper. > >>>>>> > >>>>>> The tool ignore micro version changes. > >>>>>> > >>>>>> I can contribute the tool as a project and then we can create a mvn > >>>>> plugin > >>>>>> from it or something even smarter. > >>>>>> > >>>>>> Regards, > >>>>>> Emily > >>>>>> > >>>>>> On Wed, Sep 28, 2011 at 4:16 PM, David Bosschaert < > >>>>>> [email protected]> wrote: > >>>>>> > >>>>>>> Very interesting, Emily. Would you be able to provide some > >>>> information > >>>>>>> regarding how it works? > >>>>>>> > >>>>>>> In any case I would welcome such an addition to Aries. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> > >>>>>>> David > >>>>>>> > >>>>>>> On 28 September 2011 16:02, Emily Jiang <[email protected]> > >>>>> wrote: > >>>>>>>> I have developed a semantic checking tool to check whether a > >>>> bundle's > >>>>>>>> version or the export package versions are correclty versioned > >>>>> according > >>>>>>> to > >>>>>>>> OSGi semantic versioning whitepaper. I would like to contribute to > >>>>> Apache > >>>>>>>> Aries as subproject under a code name of 'llama' ( or a better > >>>> name. > >>>>> I am > >>>>>>>> open to suggestions). > >>>>>>>> > >>>>>>>> Any thoughts or suggestions? > >>>>>>>> -- > >>>>>>>> Thanks > >>>>>>>> Emily > >>>>>>>> ================= > >>>>>>>> Emily Jiang > >>>>>>>> [email protected] > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Thanks > >>>>>> Emily > >>>>>> ================= > >>>>>> Emily Jiang > >>>>>> [email protected] > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Thanks > >>>> Emily > >>>> ================= > >>>> Emily Jiang > >>>> [email protected] > >>>> > >>> > >>> > >>> > >>> -- > >>> Alasdair Nottingham > >>> [email protected] > >>> > > > > > -- Thanks Emily ================= Emily Jiang [email protected]
