So in that case, does the timestamp qualifier get automatically added on every build? Documentation pointers welcome :)
On Thu, Jun 22, 2017 at 2:30 PM Neil Bartlett <njbartl...@gmail.com> wrote: > 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 > > > > > > > > >
