We don't like to overload the version with information about release status, so no it's not exactly like maven. An artifact is a release simply if it is present in a designated Release repository.
This enables a process where the artifact does not need to be rebuilt in order to release it. Rebuilding at such a late stage can lead to instability because small differences can creep in. Neil On 22 Jun 2017 8:23 p.m., "Justin Edelson" <jus...@justinedelson.com> wrote: > 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 > > > > >
