You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

In progress

This page is work in progress, feel free to ask on dev@sling if anything seems incorrect or is unclear

Problem statement and goals

As summarised by Stefan Seifert:

Currently we have only one launchpad in trunk, which contains a mixture of release dependencies and snapshot dependencies. this makes it difficult to release new versions because one has to release all snapshot projects first, and perhaps the last relese version is fine as well.

We came up with a new proposal to fulfill the different needs:

  1. the launchpad maintained in trunk should always be the "stable" launchpad, referencing only released dependencies of the sling bundles and oft the integration tests project
  2. the "unstable" launchpad is created dynamically from this stable launchpad by using the same bundle list, but for each dependency the latest snapshot version that is available in the maven repo, including the latest snapshot version oft he integration tests. perhaps the slingstart plugin could be extented to generate this.
  3. not sure what to do with new bundles which are not released yet thus are not referenced in the stable launchpad.

Implementation

For converting release versions to SNAPSHOT ones,  Bertrand Delacretaz has come up with a shell script that sets all dependency versions to SNAPSHOT , although it seems to not work in all situations. This script would be run on Jenkins or locally to convert the 'release' (stable) launchpad to a 'snapshot' (unstable) one.

We also discussed how to handle tests deployed under the launchpad which test functionality which is only present in SNAPSHOT versions. A proposal was made to use an annotation/assumption related to the bundles deployed in the Sling launchpad.

References:

  1. dev@sling - Launchpad stable and launchpad unstable
  2. https://svn.apache.org/repos/asf/sling/trunk/launchpad/builder/set-sling-snapshots.sh
  • No labels