Eclipse defines component version numbers as follows:
If we specify that only major releases can contain breaking/backwards incompatible changes, do we also specify that each such version must change the
major version part?
Currently it just seems to me that we are more into doing breaking changes while only incrementing the
minor part of the version, which is obviously desirable from the developer's point of view when a component is in early stages of development. Otherwise developing components will quickly end up with version 10.0.0.
Version system and assumptions
OSGi specification states version is
major.minor.service[.qualifier]. API breakage is allowed between major versions.
- Service is redundant as qualifier replaces it and is automatic
- As there is a lot of API breakage within Incubating plugins, there would be a lot of major version updates
- Simantics versioning is seen as: <super major>.<major>.<minor>.<qualifier>
- Stay true to OSGi versioning: <major>.<minor>.<service>.<qualifier>. A lot of plugins would be something like 188.8.131.52
- Modify the assumption so that, API breakage is allowed between <minor> versions, and not within a <minor>.
- Incubation Exception: If <major>==0 API breakage allowed within a <minor>. After <major> >= 1 API breakage must be introduced in the next <major> release.