Talk:Development Practices

Component versioning

Eclipse defines component version numbers as follows: major.minor.service[.qualifier].

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 code>major.minor.service[.qualifier]. Api breakage is allowed between major versions.

Issues:

• 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

Approaches:

1. Simantics versioning is seen as: <super major>.<major>.<minor>.<qualifier>
2. Stay true to OSGi versioning: <major>.<minor>.<service>.<qualifier>. A lot of plugins would be something like 12.0.0.0
3. Modify the assumption so that, API breakage is allowed between <minor> versions, and not within a <minor>.
4. Incubation Exception: If <major>==0 API breakage allowed within a <minor>. After <major> >= 1 API breakage must be introduced in the next <major> release.