Platform Team/Guide/Sweets Packaging: Difference between revisions

Line 116:

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

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

<compatibility-version>.<version>.<revision>

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

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

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

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

* the micro version is a ~~build~~ number

* the micro version is a revision number auto incremented number

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

Micro version is beeing changed by ''0sugar push'' command. It has through numbers(like Subversion 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 ''dist'' and ''dist-bin'' rewrite releases with the same ''compatibility-version.version'' versions and don't remove other releases.

'''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 ''compatibility-version.version'' versions of your service, so do not delete stable releases manually from ''dist/*.xml'' feed files and [[#Bugfix_releases|mark]] them as [[#Stability_status|buggy/insecure]] if they don't work in declared sugar environments.

== Stability status ==

One of core differences from Sucrose development process is having not stable "releases" (here, release is a result of ``0sugar push`` command). So, services need stability status. Internally each service release will have one of 0install stability [http://0install.net/interface-spec.html#id4091477 statuses]:

* ''stable'', final stable release

* ''testing'', let interested in testing people, try last changes that are not yet stable

* ''developer'', just more extreme version of ''testing''

* ''buggy'', already released versions(of any status) could be [[#Bugfix_releases|marked]] as buggy after a while to force people upgrade to new bugfix version

* ''insecure'', extreme version of ''buggy''

''0sugar push'' w/o arguments will push local changes as is. If you want to push with particular stability status, use ''0sugar push <status>''.

By default all users will use only ''stable'' versions and won't upgrade to new versions even if there are stable ones. To force people to upgrade from buggy versions, see [[#Bugfix_releases|bugfix releases]] workflow.

== Development workflows ==

Useful scenarios for service development process.

=== Having only stable releases ===

All releases of your services will have ''stable'' stability status.

* when your code is ready to release

* ''0sugar dist''/''0sugar dist_bin'' to make local releases

* ''0sugar push stable'' to rsync local releases to the server

* if it was wrong time to release and you want to re-release it, repeat previous steps to rewrite wrong release

=== Bugfix releases ===

Services assume simple versioning scheme, if you found bugs in stable version:

* either ''0sugar push stable'' release once more(users will not mess this new copy of release with previous ones)

* or ''0sugar push stable'' release with incremented ''version'' field

* if bugs are critical, mark previous release as ''buggy'' or ''insecure'' to force users upgrade their old releases. If you re-pushed release w/o incrementing ''version'' number, you should use revision number

0sugar push {buggy|insecure} {version[.revision]}

=== Development releases ===

If you want to test your new version among interested people:

* do all steps that are mentioned in previous workflows

* but use either ''testing'' or ''developer'' status for ''push'' command

* users who interested in testing(enabled testing mode) will get your new development version

== Tips ==

@@ Line 116: / Line 116: @@
 Except [[Documentation Team/Services/Native packages usage|wrappers]] for native packages(in that case, service version is version of particular native package), services use followed scheme:
-  <major-version>.<minor-version>.<micro-version>
+  <compatibility-version>.<version>.<revision>
-* the major version, ''compatibility-version'' service.info field, exposes the fact of API/ABI/data-format backward compatibility breakage
+* the major version, ''compatibility-version'' service.info field<br>exposes the fact of API/ABI/data-format backward compatibility breakage<br>only digits are allowed
-* the minor version, ''version'' service.info field, reflect on adding new features that don't break backward compatibility
+* the minor version, ''version'' service.info field<br>reflect on adding new features that don't break backward compatibility<br>only digits are allowed
-* the micro version is a build number
+* the micro version is a revision number<br>auto incremented number
-Micro version is beeing changed by ''0sugar'' implicitly after ''dist*'' and ''push'' commands. It has through numbers(like SVN revision).
+Micro version is beeing changed by ''0sugar push'' command. It has through numbers(like Subversion 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 ''dist'' and ''dist-bin'' rewrite releases with the same ''compatibility-version.version'' versions and don't remove other releases.
-'''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 ''compatibility-version.version'' versions of your service, so do not delete stable releases manually from ''dist/*.xml'' feed files and [[#Bugfix_releases|mark]] them as [[#Stability_status|buggy/insecure]] if they don't work in declared sugar environments.
+== Stability status ==
+One of core differences from Sucrose development process is having not stable "releases" (here, release is a result of ``0sugar push`` command). So, services need stability status. Internally each service release will have one of 0install stability [http://0install.net/interface-spec.html#id4091477 statuses]:
+* ''stable'', final stable release
+* ''testing'', let interested in testing people, try last changes that are not yet stable
+* ''developer'', just more extreme version of ''testing''
+* ''buggy'', already released versions(of any status) could be [[#Bugfix_releases|marked]] as buggy after a while to force people upgrade to new bugfix version
+* ''insecure'', extreme version of ''buggy''
+''0sugar push'' w/o arguments will push local changes as is. If you want to push with particular stability status, use ''0sugar push <status>''.
+By default all users will use only ''stable'' versions and won't upgrade to new versions even if there are stable ones. To force people to upgrade from buggy versions, see [[#Bugfix_releases|bugfix releases]] workflow.
+== Development workflows ==
+Useful scenarios for service development process.
+=== Having only stable releases ===
+All releases of your services will have ''stable'' stability status.
+* when your code is ready to release
+* ''0sugar dist''/''0sugar dist_bin'' to make local releases
+* ''0sugar push stable'' to rsync local releases to the server
+* if it was wrong time to release and you want to re-release it, repeat previous steps to rewrite wrong release
+=== Bugfix releases ===
+Services assume simple versioning scheme, if you found bugs in stable version:
+* either ''0sugar push stable'' release once more(users will not mess this new copy of release with previous ones)
+* or ''0sugar push stable'' release with incremented ''version'' field
+* if bugs are critical, mark previous release as ''buggy'' or ''insecure'' to force users upgrade their old releases. If you re-pushed release w/o incrementing ''version'' number, you should use revision number
+sugar push {buggy|insecure} {version[.revision]}
+=== Development releases ===
+If you want to test your new version among interested people:
+* do all steps that are mentioned in previous workflows
+* but use either ''testing'' or ''developer'' status for ''push'' command
+* users who interested in testing(enabled testing mode) will get your new development version
 == Tips ==