Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Received-SPF: pass (athena.apache.org: domain of jamie.goodyear@gmail.com
 designates 209.85.216.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAA66TpoM_aHyLrqqZgC7qKqeNOOSJZq7nOkTb9NTJ60xFH5shQ@mail.gmail.com>
References: 
 <CAA66TpoM_aHyLrqqZgC7qKqeNOOSJZq7nOkTb9NTJ60xFH5shQ@mail.gmail.com>
Date: Fri, 23 May 2014 09:39:03 -0230
Message-ID: 
 <CAJ9DK3z7fEGB-Tcx1k79dHxRSPhLszdgtqNUZqOSYg81Mj3ySg@mail.gmail.com>
Subject: Re: [DISCUSS] Semantic versioning
From: "Jamie G." <jamie.goodyear@gmail.com>
To: "dev@karaf.apache.org" <dev@karaf.apache.org>
Content-Type: text/plain; charset=UTF-8

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