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 <[email protected]> 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
