karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: [DISCUSS] Semantic versioning
Date Fri, 23 May 2014 14:19:11 GMT
First, we're talking about package versioning, not bundle versioning.
 Those are independent and the bundle version is of little use (as usually
the requirement is on the package version using a range).
And this also only apply to *exported* packages.

The main thing to consider is that the package content / version has to be
consistent, i.e. for a given package and version, the content of the
package should be the same in all branches.

So it's perfectly valid to have

| Karaf 4.0.0  |  Karaf 4.0.1 | Karaf 4.1.0 |
|  abc-4.0.0    |  abc-4.0.1   | abc-4.0.1    |

as long as the content of the package abc in 4.0.1 and 4.1.0 are the same.
 And that goes down to the implementation too, as the interface is the
contract really.

The "problems" come when you have a modification which is small new
feature, but fully compatible.  For example, you add a  method to an
interface which is consumed by users (i.e. not implemented).  In that case,
the semantic versioning rules lead to raising the version from 4.0.0 to
4.0.1.  so let's say we release this in the 4.1.x branch.
If we later find a bug that require another modification of this interface,
we need to increase the package to 4.0.2 and release that package in both
4.0.x and 4.1.x branches, meaning we also need to backport the new feature
added with the 4.0.1 package.

Note that the whole scenario is questionable, as changing the api for a bug
fix might not be considered a bug fix anymore, but i think we had to do
that in the past, and I don't see how we could avoid that in the future.
 If such a case happen, we'd have to decide on a case by case to either not
backport the bug that require an api change, or have to backport all api
changes (and related implementations).   That's why some projects end-up
actually having a separate release cycle for each bundle.



2014-05-23 14:09 GMT+02:00 Jamie G. <jamie.goodyear@gmail.com>:

> I believe that last point needs to be a little clearer too ;)
>
> Forgive my attempt at ascii table:
>
> | Karaf 4.0.0  |  Karaf 4.1.0 |
> |  abc-4.0.0    |  abc-4.0.1   |
>
> Bug in abc is found, requiring a patch:
>
> | Karaf 4.0.1  |  Karaf 4.1.0 | Karaf 4.1.1 |
> |  abc-4.0.2    |  abc-4.0.1   | abc-4.0.2    |
>
> Would the above table describe the releases?
>
> Why can't we have the following, where abc-4.0.1 are the same bug fix
> release?
>
> | Karaf 4.0.0  |  Karaf 4.0.1 | Karaf 4.1.0 |
> |  abc-4.0.0    |  abc-4.0.1   | abc-4.0.1    |
>
> Cheers,
> Jamie
>
> On Thu, May 22, 2014 at 11:31 AM, Guillaume Nodet <gnodet@apache.org>
> wrote:
> > A recent contribution to the felix maven-bundle-plugin is that baseline
> > goal which checks and/or reports semantic versioning changes.
> > It basically does a binary diff with the latest release of the same
> > artifact for changes and verify that the changes are compatible with the
> > semantic versioning rules.
> >
> > I think we should try to leverage those, but without changing our release
> > lifecycle.  This could be done the following way:
> >   * keep our artifacts versioning and release mechanism untouched
> >   * add the baseline plugin
> >   * in 4.0, exported packages would all have a version of 4.0.0
> >   * follow semantic versioning for all releases > 4.0
> >
> > This would mean that karaf 4.1 would have packages in version 4.0, 4.0.1
> or
> > 4.1.  Note that the version used for karaf (and for bundles) isn't tied
> in
> > any way to the version of the packages.
> > But this would also help making sure we stay compatible, and whenever we
> do
> > a new release (be it 4.1 or 5.0), help users with migration because the
> > package versions would not be changed unless needed.
> >
> > Downsides:
> >   * users may be impacted in the future with the fact that not all
> packages
> > have the same version, but this should usually be minor, as tools usually
> > grab the version of the packages from the binary when writing an import
> > package.  However, for those which do not leverage those features, this
> > will have an impact
> >   * bug fix releases may be more tricky : the main problem is that with
> > semantic versioning, once a package is released with a minor upgrade,
> > there's no room left
> >
> > The last point needs an explanation.  Let's say we have a package in
> > version 4.0.0 in karaf 4.  We later release karaf 4.1 with a very minor
> > addition to that package, so that this package is now in version 4.0.1.
>  If
> > we later find  a bug which require a fix, we won't be able to release a
> > karaf 4.0.1 with a micro change in that package, so we'd have to at least
> > backport the interface change from 4.1 in 4.0.1 (even if we don't
> backport
> > the implementation) and then do the fix with a 4.0.2 package version.
> >
> > Not sure this is very clear, but the last point has always been my worry
> > about semantic versioning.
> >
> > Thoughts ?
> >
> > Guillaume
>

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