5,705
edits
Changes
Jump to navigation
Jump to search
Line 112:
Line 112: − 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).+ − + − + + +
Platform Team/Guide/Sweets Packaging (view source)
Revision as of 18:02, 27 December 2009
, 18:02, 27 December 2009→Versioning scheme
== Versioning scheme ==
== Versioning scheme ==
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>
<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
* 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.
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.