Talk:Development Practices - Revision history

Tuukka Lehtonen: /* Version system and assumptions */

2010-11-01T10:56:01Z

Version system and assumptions

← Older revision		Revision as of 10:56, 1 November 2010
Line 10:		Line 10:
	== Version system and assumptions ==		== Version system and assumptions ==

	OSGi specification states version is code>major.minor.service[.qualifier]</code>. ~~Api~~ breakage is allowed between major versions.		OSGi specification states version is <code>major.minor.service[.qualifier]</code>. API breakage is allowed between major versions.

	Issues:		Issues:

Toni Kalajainen at 10:50, 1 November 2010

2010-11-01T10:50:25Z

← Older revision		Revision as of 10:50, 1 November 2010
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.

Tuukka Lehtonen: Component versioning

2010-11-01T09:44:17Z

Component versioning

New page

== Component versioning ==

Eclipse defines component version numbers as follows: <code>major.minor.service[.qualifier]</code>.

If we specify that only major releases can contain breaking/backwards incompatible changes, do we also specify that each such version must change the <code>major</code> version part?

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.