5,705
edits
Changes
Jump to navigation
Jump to search
Line 106:
Line 106: − + − + − + + − +
Platform Team/Guide/Sweets Packaging (view source)
Revision as of 04:11, 26 December 2009
, 04:11, 26 December 2009→Versioning scheme
== Versioning scheme ==
== Versioning scheme ==
Service are welcome to use API changes based versioning scheme(except obvious cases then service uses upstream versions):
Service are welcome to use API changes based versioning scheme. Except obvious cases then service uses upstream versions but even in that case using separate service versions could benefit users, see [[Activity Team/Services/Glucose|Glucose]] service:
<major-version>.<minor-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 starts from ''0''(premature state) and exposes the fact of API backwards compatibility breakage
* the minor version is for bugfixes and features that don't break backwards compatibility
* the minor version reflect on adding new features that don't break backwards compatibility
* the micro version is a build number
Commands like ''dist'' and ''dist-bin'' don't remove previous versions from feed(you still can manually remove them from ''dist/feed.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.
'''NOTE''': Be careful, some services and activities could be stuck to particular versions(major versions) of your service, so do not delete stable releases if they still work in declared sugar environments.
'''NOTE''': Be careful, some services and activities could be stuck to particular versions(major versions) of your service, so do not delete stable releases if they still work in declared sugar environments.