Platform Team/Guide/Sweets Packaging: Difference between revisions

Line 112:

== Versioning scheme ==

~~Services are welcome to use(fully or partially) API changes based versioning scheme (except obvious cases then service is a~~ [[Documentation Team/Services/Native packages usage|~~wrapper~~]] to native package).

Except [[Documentation Team/Services/Native packages usage|wrappers]] for native packages(in that case, service version is version of particular native package), services use API changes based versioning scheme:

<major-version>.<minor-version>.<micro-version>

* the major version ~~starts from~~ ''0''~~(premature state) and~~ exposes the fact of API ~~backwards~~ compatibility breakage

* the major version, ''compatibility-version'' service.info field, exposes the fact of API/ABI/data-format backward compatibility breakage

* the minor version reflect on adding new features that don't break ~~backwards~~ compatibility

* the minor version, ''version'' service.info field, reflect on adding new features that don't break backward compatibility

* the micro version is a build number

Micro version is beeing changed by ''0sugar'' implicitly after ''dist*'' and ''push'' commands. It has through numbers(like SVN revision).

Commands like ''dist'' and ''dist-bin'' don't remove previous versions from feed(you still can manually remove them from ''dist/*.xml'') so, new release doesn't break code which depends on your service.

@@ Line 112: / Line 112: @@
 == Versioning scheme ==
-Services are welcome to use(fully or partially) API changes based versioning scheme (except obvious cases then service is a [[Documentation Team/Services/Native packages usage|wrapper]] to native package).
+Except [[Documentation Team/Services/Native packages usage|wrappers]] for native packages(in that case, service version is version of particular native package), services use API changes based versioning scheme:
   <major-version>.<minor-version>.<micro-version>
-* the major version starts from ''0''(premature state) and exposes the fact of API backwards compatibility breakage
+* the major version, ''compatibility-version'' service.info field, exposes the fact of API/ABI/data-format backward compatibility breakage
-* the minor version reflect on adding new features that don't break backwards compatibility
+* the minor version, ''version'' service.info field, reflect on adding new features that don't break backward compatibility
 * the micro version is a build number
+Micro version is beeing changed by ''0sugar'' implicitly after ''dist*'' and ''push'' commands. It has through numbers(like SVN revision).
 Commands like ''dist'' and ''dist-bin'' don't remove previous versions from feed(you still can manually remove them from ''dist/*.xml'') so, new release doesn't break code which depends on your service.