Difference between revisions of "Talk:Development Practices"
Jump to navigation
Jump to search
(Component versioning) |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 6: | Line 6: | ||
Currently it just seems to me that we are more into doing breaking changes while only incrementing the <code>minor</code> 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. | Currently it just seems to me that we are more into doing breaking changes while only incrementing the <code>minor</code> 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]</code>. 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: | ||
| + | # 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 12.0.0.0 | ||
| + | # 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. | ||
Latest revision as of 10:56, 1 November 2010
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 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:
- 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 12.0.0.0
- 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.
