Jubula/JubulaRententionPolicy

Retention Policy for Jubula builds

Code in git

All code that was included in a release is left in git forever. The version of a module that is included in a release will typically have a convenience version tag on the module, such as "R3_7_0". The release build tags would be something like "vM20100211202452" where the date-time-stamp matches the one on the download page and zip file names.

Distributions in zip files

Formal releases are kept forever, but only the most recent release is kept on the main download page. Other, older distributions can be found (as soon as they exist, which will be after the Indigo release) on the archive site.

While developing a new releases, milestone builds are kept until the release, at which point they are deleted.

Similarly, while developing a milestone, weekly integration builds are kept until the milestone is available, and then they are deleted.

Features in update site repository

Only the most recent release (and/or patches) are kept on the update site. The goal is to allow users to update to the latest code from what they have installed, but we don't support updating to some previous release. For example, if we come out with a "1.0.3", the "1.0.2" version won't be on the update site any longer. So, someone with "1.0.0" installed could update to "1.0.3", but they could no longer update only to "1.0.2", once 1.0.3 was released.

Starting with Indigo, our plan is that our "update site URL" in features and otherwise "published for use", will refer to a software repository, specific to a yearly release. For example,

http://download.eclipse.org/jubula/release/indigo/

Zip files for patches or update sites

The patch builds are not retained.

There is no guarantee or predicable time line. The builds are created at the request of committers, usually for some specific adopter problem, and generally not for general use. They are use-at-your-own risk, if someone does want to use it, since hasn't been through the usual review and test cycle.

There are some cases, when updates are created in the form of feature patches and put on the public update site. These require PMC review/approval since could effect general users and all adopters. These patches on the update site will follow the update site repository policy.

What if these policies don't work for you?

Just ask. Open a bug or post a note to jubula-dev and request what you need. For example, an adopter might be building against an I-build, and isn't ready to move up to a particular milestone build for a few more weeks, so they'd prefer some I-build to not be removed at the end of the milestone.

In other words, we are glad to be accommodating, but don't want to accommodate every hypothetical combination, since it's more work for us, we don't test it, and requires higher disk and bandwidth on the Eclipse mirroring system. So, open a bug if something special is required.