felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Bartlett <njbartl...@gmail.com>
Subject Re: API baselining with maven-bundle-plugin
Date Thu, 22 Jun 2017 18:30:08 GMT
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" <justin@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 <njbartlett@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.quarendon@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:justin@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.quarendon@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:justin@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.quarendon@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-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message