Neil- Out of curiosity, in the bnd worldview you're describing, how is the distinction between a snapshot and release denoted? Is it like Maven where SNAPSHOT is used as a qualifier? Or is there some other convention?
Thanks, Justin On Thu, Jun 22, 2017 at 1:51 PM Neil Bartlett <njbartl...@gmail.com> wrote: > Are you sure that you’re actually *releasing* every day? Or do you only > mean sending out snapshots? > > I agree with Justin that releases should be immutable, and that is what > bnd and Bndtools have always tried to achieve. However bnd is not a > complete end-to-end build system like Maven or Gradle, and Bndtools is only > an IDE, so we don’t get a lot of say in the larger process. You should work > within the conventions of whatever build tool you use. > > The process encouraged by bnd is very close to the Maven one. Once a > release is made, you must not change it. If you change a package after a > release, then you move up to a new version number for that package. You can > then build and publish as many snapshot of that new version number as you > like, usually with a timestamp in the qualifier segment of the version. > Once you release, that version is consumed and you go back to the beginning > of this paragraph. > > Neil > > > > On 22 Jun 2017, at 18:12, Tom Quarendon < > tom.quaren...@worldprogramming.com> wrote: > > > > The cadence is important I that if I want to "release" off the back of > each build, I don't want to have to manually make a code modification every > day, nor do I want to have the build process modify the source code, that > just doesn't seem right. > > > > I'm probably at odds with standard practice. > > > > -----Original Message----- > > From: Justin Edelson [mailto:jus...@justinedelson.com] > > Sent: 22 June 2017 17:40 > > To: users@felix.apache.org > > Subject: Re: API baselining with maven-bundle-plugin > > > > 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. > >>> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > > For additional commands, e-mail: users-h...@felix.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > >
