ignazio1977
commented
7 years ago ?
Open sesuncedu opened 7 years ago
ignazio1977
commented
7 years ago ?
sesuncedu
commented
7 years ago THE VERSION NUMBER IS A LIE!
ignazio1977
commented
7 years ago I'm not clear on the definition of truth.
sesuncedu
commented
7 years ago 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:
sesuncedu
commented
7 years ago 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. Semantic Versioning 2.0.0 - http://semver.org/
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
ignazio1977
commented
7 years ago 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.
sesuncedu
commented
7 years ago The numbering makes it much easier to have backwards compatibility (and not have 5 different versions of owlapi loaded in the same runtime). They're different from human consumable release numbers :)
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.
ansell
commented
7 years ago Should we look into making the next OWLAPI major release consistent with the OSGi package numbers?
ansell
commented
7 years ago 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.
sesuncedu
commented
7 years ago 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