The cadence of releases is irrelevant. But each release must have a distinct (bundle) version number. Otherwise, the version loses any meaning since two copies of "version 1.0.0" are not necessarily the same.
If you only want to change the bundle version when you start changing the project, that's certainly a choice you can make. I find (and many others do too) it easier to do this automatically at the time of release (i.e. set the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't get forgotten. I can't speak to how bndtools work. I assume it must do some kind of automatic bundle version management since it would be inappropriate to have mutable releases. On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon < tom.quaren...@worldprogramming.com> wrote: > I perhaps have a different concept of how things work. But I'm not very > familiar with how maven works. > > Fundamentally, if I haven't changed any code, why have any of the version > numbers changed? I'm perhaps viewing things from a continuous deployment > perspective rather than a "release once a year" perspective. > > As far as I can tell with bndtools, version numbers are changed as, and > only as necessary. > I check out the source code, and then as I change code, it prompts me to > change package and bundle versions appropriately. > Hence after my edits, the package and version numbers of things I haven't > changed are the same as they were, which seems right to me. Things that > I've changed have changed version package and bundle version numbers. > If I then do a "mvn deploy" (well, "gradle release") on the result, then > OK, the unchanged bundles will be re-released to the repository (or maybe > not, maybe maven/gradle doesn't replace a bundle with one with the same > version, don't know), but the contents are the same (from a source > perspective anyhow), so that doesn't matter. > > As I say, I don't have much experience of using maven etc, I was confused > that it worked in an apparently different way to bndtools, which is based > on the same thing. > > > > -----Original Message----- > From: Justin Edelson [mailto:jus...@justinedelson.com] > Sent: 22 June 2017 15:15 > To: users@felix.apache.org > Subject: Re: API baselining with maven-bundle-plugin > > Hi, > I think you might be mixing up the bundle version (what I think you are > referring to as the "project version") with the package versions. baseline > is larger concerned with the latter, and only uses the former to find the > comparison version. > > Released versions should always be considered immutable, so you should > *always* change the project version immediately after a release. If you > use the maven-release-plugin, this is automatically done, but otherwise you > would need to do this manually. > > Here's the way it is supposed to work: > > * You have a bundle with version 1.0.0 and package com.myco.foo at version > 1.0.0. This bundle is deployed in some repository. > * The current version of the bundle is now 1.0.1.SNAPSHOT (or > 1.0.1-SNAPSHOT in Maven terms). > * You make some change to one of the classes/interfaces in com.myco.foo. > * Then you run the baseline plugin. Baseline compares the current state > against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and checks each > exported package. It sees that there has been some change in com.myco.foo > which requires that the package version change. It then alerts you to this > change and recommends a new package version number. Alternatively, if you > changed the exported package version, baseline will still tell you that > there was a change made but that you have already correctly changed the > package version number. > > HTH, > Justin > > On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon < > tom.quaren...@worldprogramming.com> wrote: > > > I'm trying to set up api baselining using the maven-bundle-plugin. > > > > I think I have it set up. I have messages coming out that say it's > > doing stuff. So that's good. > > > > Forgive my confusion though, but I don't understand how it is supposed > > to work. > > I have published a 1.0.0 version of my bundle to the repository. > > I then make an incompatible change to the API, I get: > > Unable to find a previous version of the project in the repository > > > > If I manually change the version number in my pom to 1.0.1, I then get > > errors about my API having changed and it requiring a change in > > version number. > > > > So I don't understand. I only get a baseline check once I've > > remembered to change the version number? Surely the point is to tell > > me that I *need* to change the version number? That's certainly the > > support you get in bndtools (being also based on bnd, same as the maven > plugin). > > > > Have I set it up correctly? Or is this how it's supposed to work? > > In the configuration, it looks like the setting comparisonVersion is > > initialised to (,${project.version}) by default, presumably meaning > > "up to and not including ${project.version}". > > Changing that to be (,${project.version}] makes it do a comparison, > > but produces no errors, presumably because it's comparing the bundle > > against itself. What I want it to do is compare against the current > > latest in the release repository. > > > > So I'm confused. How do I make it tell me that I need to change my > > project version, without first changing my project version? > > > > Thanks. > > >
