5,705
edits
Changes
Platform Team/Guide/Sweets Packaging (view source)
Revision as of 05:15, 29 December 2009
, 05:15, 29 December 2009→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 followed 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 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
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 ==
== Tips ==