Platform Team/Guide/Sweets Packaging: Difference between revisions

Line 169:

== Releasing ==

In Sweets, releasing means uploading sources tarball with a release (though, that [[#Stability_status|doesn't mean]] ~~only~~ stable versions) to the Sugar Labs [[Platform_Team/Open_Build_System|instance]] of the [http://openbuildservice.org/ Open Build Service] (OBS). Before releasing, make sure that you have Sugar Labs [[Service/Account#Sugar_Labs_Central_Login|account]]. ~~The~~ login ~~and~~ password will be ~~asked for~~ the first time.

In Sweets, releasing means uploading a sources tarball with a release (though, that [[#Stability_status|doesn't only mean]] stable versions) to the Sugar Labs [[Platform_Team/Open_Build_System|instance]] of the [http://openbuildservice.org/ Open Build Service] (OBS). Before releasing, make sure that you have a Sugar Labs [[Service/Account#Sugar_Labs_Central_Login|account]]. A login with password will be required the first time or when your cookie is missing.

Before releasing, make sure that your recipe conforms OBS [[Platform_Team/Open_Build_System/Policy|Policy]]. While releasing, sweet sources will be uploaded to OBS project/package according to the [[#Interfaces|implement]] recipe option. If particular project or package don't exist, they will be created (~~with requesting for~~ user's confirmation for project creation).

Before releasing, make sure that your recipe conforms to the OBS [[Platform_Team/Open_Build_System/Policy|Policy]]. While releasing, sweet sources will be uploaded to an OBS project/package according to the [[#Interfaces|implement]] recipe option. If a particular project or package don't exist, they will be created (upon user's confirmation for project creation).

To initiate releasing, ~~type~~ from the sweet sources directory:

To initiate releasing, enter from the sweet sources directory:

sweets commit

The {{Code|sweets}} command will ask for commit message, i.e., release notes. The same notes might be passed to {{Code|commit}} command via {{Code|--message}} command-line argument.

The {{Code|sweets}} command will ask for a commit message, i.e., release notes. The same notes might be passed to {{Code|commit}} command via the {{Code|--message}} command-line argument.

If releasing sweet is a binary based, only recent stable version will be built on the OBS side, other versions will be built on a client side.

If the releasing sweet is binary based, only the most recent stable version will be built on the OBS side, other versions will be built on the client side.

== Development with Sweets ==

Source bundles might be used on a client side not only indirectly, via {{Code|sweets}} command for example, but also explicitly. Sources might be bundled, emailed, etc. In this case, it is ~~no different from~~ {{Code|.xo}} files. To make sources useful within Sweets, the local directory with sources might be ~~used~~ in several ways:

Source bundles might be used on the client side not only indirectly, via {{Code|sweets}} command for example, but also explicitly. Sources might be bundled, emailed, etc. In this case, it is just like {{Code|.xo}} files. To make sources useful within Sweets, the local directory with sources might be employed in several ways:

* Applications might be launched from sources, {{Code|sweets ''<path-to-sources>''}};

* To reuse sources as dependencies for other sweets, source directory needs to be registered in Sweets, {{Code|sweets checkout ''<path-to-sources>''}}; applications might be checked out as well.

* To reuse sources as dependencies for other sweets, the source directory needs to be registered in Sweets, {{Code|sweets checkout ''<path-to-sources>''}}; applications might be checked out as well.

Checking out will register a ''sweet'' in the local ''Sweets'' instance as a single ''implementation'' for the ''interfaces'' it ''implements''. This feature is especially useful for libraries, for example, if the sugar-toolkit sources, which implement the {{Code|sdk/sugar-toolkit}} ''interface'', were cloned to the {{Code|~/src/sugar-toolkit}} directory, then, while running a {{Code|sdk/sugar}} ''sweet'', it would become possible to reuse local sugar-toolkit sources as a regular ''implementation'' of the {{Code|sdk/sugar-toolkit}} dependency of {{Code|sdk/sugar}}.

@@ Line 169: / Line 169: @@
 == Releasing ==
-In Sweets, releasing means uploading sources tarball with a release (though, that [[#Stability_status|doesn't mean]] only stable versions) to the Sugar Labs [[Platform_Team/Open_Build_System|instance]] of the [http://openbuildservice.org/ Open Build Service] (OBS). Before releasing, make sure that you have Sugar Labs [[Service/Account#Sugar_Labs_Central_Login|account]]. The login and password will be asked for the first time.
+In Sweets, releasing means uploading a sources tarball with a release (though, that [[#Stability_status|doesn't only mean]] stable versions) to the Sugar Labs [[Platform_Team/Open_Build_System|instance]] of the [http://openbuildservice.org/ Open Build Service] (OBS). Before releasing, make sure that you have a Sugar Labs [[Service/Account#Sugar_Labs_Central_Login|account]]. A login with password will be required the first time or when your cookie is missing.
-Before releasing, make sure that your recipe conforms OBS [[Platform_Team/Open_Build_System/Policy|Policy]]. While releasing, sweet sources will be uploaded to OBS project/package according to the [[#Interfaces|implement]] recipe option. If particular project or package don't exist, they will be created (with requesting for user's confirmation for project creation).
+Before releasing, make sure that your recipe conforms to the OBS [[Platform_Team/Open_Build_System/Policy|Policy]]. While releasing, sweet sources will be uploaded to an OBS project/package according to the [[#Interfaces|implement]] recipe option. If a particular project or package don't exist, they will be created (upon user's confirmation for project creation).
-To initiate releasing, type from the sweet sources directory:
+To initiate releasing, enter from the sweet sources directory:
   sweets commit
-The {{Code|sweets}} command will ask for commit message, i.e., release notes. The same notes might be passed to {{Code|commit}} command via {{Code|--message}} command-line argument.
+The {{Code|sweets}} command will ask for a commit message, i.e., release notes. The same notes might be passed to {{Code|commit}} command via the {{Code|--message}} command-line argument.
-If releasing sweet is a binary based, only recent stable version will be built on the OBS side, other versions will be built on a client side.
+If the releasing sweet is binary based, only the most recent stable version will be built on the OBS side, other versions will be built on the client side.
 == Development with Sweets ==
-Source bundles might be used on a client side not only indirectly, via {{Code|sweets}} command for example, but also explicitly. Sources might be bundled, emailed, etc. In this case, it is no different from {{Code|.xo}} files. To make sources useful within Sweets, the local directory with sources might be used in several ways:
+Source bundles might be used on the client side not only indirectly, via {{Code|sweets}} command for example, but also explicitly. Sources might be bundled, emailed, etc. In this case, it is just like {{Code|.xo}} files. To make sources useful within Sweets, the local directory with sources might be employed in several ways:
 * Applications might be launched from sources, {{Code|sweets ''<path-to-sources>''}};
-* To reuse sources as dependencies for other sweets, source directory needs to be registered in Sweets, {{Code|sweets checkout ''<path-to-sources>''}}; applications might be checked out as well.
+* To reuse sources as dependencies for other sweets, the source directory needs to be registered in Sweets, {{Code|sweets checkout ''<path-to-sources>''}}; applications might be checked out as well.
 Checking out will register a ''sweet'' in the local ''Sweets'' instance as a single ''implementation'' for the ''interfaces'' it ''implements''. This feature is especially useful for libraries, for example, if the sugar-toolkit sources, which implement the {{Code|sdk/sugar-toolkit}} ''interface'', were cloned to the {{Code|~/src/sugar-toolkit}} directory, then, while running a {{Code|sdk/sugar}} ''sweet'', it would become possible to reuse local sugar-toolkit sources as a regular ''implementation'' of the {{Code|sdk/sugar-toolkit}} dependency of {{Code|sdk/sugar}}.