Welcome to owlapi version 10 #624
Comments
|
? |
|
THE VERSION NUMBER IS A LIE! |
|
I'm not clear on the definition of truth. |
|
Since the actual release history has used package version numbers that are the same as the maven version number, an alternative re-numbering scheme would be:
|
|
The package version numbers in the initial message are the version numbers that should have been used in the current version of the api if numbers had been bumped appropriately according to the principals of semantic versioning for each release in the 5.0.* series. See e.g.
|
|
OK, so we've made less minor releases than strictly required. I question whether strict adherence to this scheme solves the problem presented, i.e., dependency hell. I have the feeling more versions make it worse, not better. |
|
The numbering makes it much easier to have backwards compatibility (and not have 5 different versions of owlapi loaded in the same runtime). Ideally, packages that are not supposed to be for general use would be made private. Also, packages and bundles could be made smaller, with a smaller API surface. |
|
Should we look into making the next OWLAPI major release consistent with the OSGi package numbers? |
|
Overall though I think the BND automated detection of "new functionality" is too vigourous, and even strict SemVer advocates wouldn't advocate for requiring a new minor release for every new field or method just for the sake of it if the patch could otherwise fit into a smaller and sooner to be released patch version. Once we fully support SemVer, we could still support multiple major versions of OWLAPI on the classpath by changing package names to include the major version number. In terms of stable API's, it may be more useful to release multiple beta versions of major version releases and work through any small niggles before actually releasing X.0.0 so we are less likely to need to release an incompatible X.0.1 release to patch a major bug that can't be patched while keeping the API backwards compatible. |
|
On Feb 23, 2017 8:50 PM, "Peter Ansell" <notifications@github.com> wrote:
Overall though I think the BND automated detection of "new functionality"
is too vigourous, and even strict SemVer advocates wouldn't advocate for
requiring a new minor release for every new field or method just for the
sake of it if the patch could otherwise fit into a smaller and sooner to be
released patch version.
JAPICMP seems pickier about some things. I haven't wired up the semver
switch yet. BTW, I switched the gradle japicmp to base against the last
release, rather than at 5.0.0. Didn't know what to do for the pom.
The key is that the versioning is done at a finer level, and only publicly
exposed APIs need bumps. Clients by default import packages from the
current minor release up to the next major.
At the moment, everything in owlapi is exported, so internal changes are
more visible (also a problem with mixing internals and external classes in
the same package, which jigsaw is going to make people notice).
The problem is that we are conditioned to seeing minor version bumps as
being more significant than they are in a semver sense.
|
Starting from owlapi-5.0.0, then incrementing version numbers in accordance with semantic versioning principles have the following sequence of changes in package version numbers. I am leaving out bumps in the micro version.
5.0.1
The Bundle-Version should be 6.0.0, as there is a major version change.
5.0.2
The Bundle-Version should be 7.0.0, as there is a major version change.
5.0.3
The Bundle-Version should be 8.0.0, as there is a major version change.
5.0.4
The Bundle-Version should be 8.1.0, as there is a minor version change.
5.0.5
The Bundle-Version should be 9.0.0, as there is a major version change.
5.0.6-SNAPSHOT (as of even date)
The Bundle-Version should be 10.0.0, as there is a major version change.
Packages which are still at 5.0.X
Note: The micro part of the version number has been bumped when either the bnd baseline tool detects a micro change, or the sha1 digest of the class file changes. These numbers are as of 5.0.6-SNAPSHOT.
Additional packages still matching 5.X.X
Packages that are no longer backwards compatible with 5
The text was updated successfully, but these errors were encountered: