Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Orbit/Promotion, Release, and Retention Policies"

(Milestones and Final Bundles Area)
m (Milestone Release Process)
(23 intermediate revisions by 6 users not shown)
Line 1: Line 1:
Orbit itself does not have releases, per se, since the 3rd party jars that are bundled have already been released. But, we will still use the Eclipse Simultaneous Release rhythm to set deadlines for ourselves and promote and retain bundles.  
+
Orbit itself does not have releases, per se, since the 3rd party jars that are bundled have already been released. But, we will still use the Eclipse [[Simultaneous Release]] rhythm to set deadlines for ourselves and promote and retain bundles.  
  
An Orbit milestone date will be considered the same as the base Eclipse platform milestone date, since for anyone in a Simultaneous Release to use an Orbit Bundle, it would have to be ready (and final) at least a week or two before their milestone deadline.  
+
An Orbit milestone date will be considered the same as the base Eclipse platform milestone date, since for anyone in a [[Simultaneous Release]] to use an Orbit Bundle, it would have to be ready (and final) at least a week or two before their milestone deadline.  
  
 
=== Continuous Builds ===
 
=== Continuous Builds ===
  
Our continuous builds produce builds in the [http://download.eclipse.org/tools/orbit/committers/ committers area].
+
Our continuous builds produce builds on the [http://download.eclipse.org/tools/orbit/downloads downloads page].
Their purpose is for the committers to have something to see or download and confirm all is as they expect it to be. These builds are often short lived and can be deleted without notice.  
+
Their purpose is for the committers to have something to see or download and confirm all is as they expect it to be. These builds are often short lived and can be deleted without notice.
  
=== Weekly Declared Builds ===
+
Note that all new changes eventually trigger an integration (I) build that gets automatically promoted to the downloads page.
  
Once per week, currently by Monday noon (Eastern time), the latest continuous build will be copied over to the [http://download.eclipse.org/tools/orbit/downloads downloads area]. These are similar or analogous to weekly Integration Builds, and will be retained in place until the Milestone release.  
+
=== Milestone Release Process ===
 +
 
 +
# Log in with your committer account on https://ci.eclipse.org/orbit/
 +
# Go to the [https://ci.eclipse.org/orbit/job/orbit-recipes/ orbit-recipes] JIPP
 +
## Click 'Build with Parameters'
 +
## Change the <code>BUILD_LABEL</code> to <code>S</code> using the drop-down box, to indicate a stable build
 +
## Make sure <code>SIMREL_NAME</code> is set to the name of the simultaneous release (eg. 2019-03) to which this build will contribute
 +
## Leave everything else as-is, and click build
 +
## Once the build succeeds, click the 'Keep this build forever' button, and add a description for the build (eg. 2019-03 M3).
 +
## Also, take note of the timestamp used for the build at the bottom of the log file
 +
# Modify the <code>notes.php</code> file to include a line containing the milestone build, and it's name (eg. $notes["S12345678901234"]="2019-03 M3"; )
 +
# Go to the [https://ci.eclipse.org/orbit/job/promote-to-downloads/ promote-to-downloads] JIPP
 +
## Click 'Build with Parameters'
 +
## Change <code>SRC_LOCATION</code> to the path of the milestone build folder, relative to the root of the orbit folder and click build. For example, if the build was created at ' http://download.eclipse.org/tools/orbit/S-builds/S12345678901234/', then <code>SRC_LOCATION</code> would be <code>S-builds/S12345678901234/</code>
 +
## The build should appear in the downloads page shortly
 +
# Announce the release of the milestone build on the orbit-dev mailing list.
 +
# Once you have made the announcement,  the build is considered released. Be sure to update the <code>referenceRepoBuild</code> in <code>releng/mavenparent/pom.xml</code> property to reference the released build. This will ensure that new packages introduced in this (just announced) release have their timestamps frozen until further possible changes are introduced.
  
 
=== Milestones and Recommended ("Final") Bundles Area ===
 
=== Milestones and Recommended ("Final") Bundles Area ===
  
Once per milestone, (roughly simultaneous with the platform's milestone), the most recent Weekly Build will be declared the milestone build, and the earlier weekly builds deleted. The bundles from that milestone build, that committers judge as finished, will be copied to the [http://download.eclipse.org/tools/orbit/downloads/ downloads directory]. This is to be considered the final home for the bundles added to Orbit. That is, these final bundles should not normally ever have to be re-built. In case they do, they will have different qualifiers in the fourth field. In this case, the older qualified versions will be kept for approximately 1 milestone period, to give consumers a chance to update any build scripts, without suddenly breaking their builds.  We anticipate it being very rare to have to change a bundle after being moved to the final bundles area. Each Milestone Build will be retained until an Eclipse Simultaneous Release and then all deleted.  
+
Once per milestone, (roughly simultaneous with the platform's milestone), a rebuild will occur on the latest commit, and the earlier weekly builds may be deleted. Each Milestone Build will be retained until an Eclipse Simultaneous Release and then all deleted.  
  
<del>
 
'''Issue: ''' This permanent home for the bundles will not have "timestamp" directories, so it is easier to specify a permanent URL, write scripts, etc. The issue is that while these can currently be easily obtained one by one, but we have not yet decided what, if any, archive or update files to create for these final bundles.
 
</del>
 
 
<p>
 
<p>
 
It was decided in June 12, 2007 status meeting to (still) have dated directories for the "final" builds, and was decided to call them "R-builds", which may sound like "Released", but is "Recommended" for Orbit, since Orbit does not have Releases in the Eclipse sense of that word.
 
It was decided in June 12, 2007 status meeting to (still) have dated directories for the "final" builds, and was decided to call them "R-builds", which may sound like "Released", but is "Recommended" for Orbit, since Orbit does not have Releases in the Eclipse sense of that word.
  
The bundles in "Recommended" builds will only be changed (re-created) if there are serious bugs found with them. Even then, any "Recommended" builds will be retained long term, such as for 2 years or so, so build scripts will not break and be recreatable. It is expected that Recommended builds will be produced once or twice per year. Certainly for any yearly trains, but perhaps at other times, since not all projects always have to release only in June.
+
The bundles in "Recommended" builds will only be changed (re-created) if there are serious bugs found with them. Even then, any "Recommended" builds will be retained long term, such as for 2 years or so, so build scripts will not break and be re-creatable.
 +
 
 +
==== Milestones and Recommended Build "Notes" Column ====
 +
 
 +
On the main download page is a column labeled "Notes". While technically any "note" can be put in there, at a minimum for every "R-build" and "S-build" a note should be added for which Simultaneous Release the build was first recommended for.
 +
 
 +
Adding notes to the file is a matter of "hand editing" the "notes.php" file on the download server. It is under
 +
 
 +
.../tools/orbit/downloads/
 +
 
 +
and new entries are added, by adding new array entries, which are indexed by the "display name" of the download. For example, if existing file started with the following:
 +
 
 +
<?php
 +
 +
$notes = array();
 +
 +
$notes["R20140525021250"]="Luna, Luna SR1";
 +
$notes["R20140114142710"]="Kepler SR2";
 +
 +
then the next R-build was for Mars, and named R201506011000, and no new R-build for Luna SR2, that file would end up starting with:
 +
 
 +
<?php
 +
 +
$notes = array();
 +
 +
$notes["R20150601100000"]="Mars";
 +
$notes["R20140525021250"]="Luna, Luna SR1, Luna SR2";
 +
$notes["R20140114142710"]="Kepler SR2";
 +
 
 +
This file, and others are stored in module org.eclipse.orbit.releng.downloadsites but there is no automatic update or anything from those files, to download server.
  
 
=== Milestone dates ===
 
=== Milestone dates ===
  
The Orbit milestones should be -1 week from the Europa milestones to allow Europa teams to adopt the stable Orbit bundles in their builds.
+
The Orbit milestones dates will be a -1 delivery in Simultaneous Releases, to allow all projects to pick up prereqs (even the Platform, the 0 delivery).
 +
 
 +
=== Build Retention ===
 +
 
 +
Milestone builds will be retained until the Recommend build is produced.
 +
 
 +
Recommended builds will be kept forever, the most recent one(s) on 'download.eclipse.org' but older ones will be moved to 'archive.eclipse.org' (which is not mirrored) The old, archived builds should rarely be needed, used only be used if someone needed to re-create some old build which was based upon it, such as for long term maintenance.
 +
 
 +
=== Bundle Retention in active builds ===
  
Thus the Orbit Milestone dates would be
+
It is our Orbit project's policy that once a bundle is delivered in an R-build, it will be retained forever in that R-build (or its repository). But, in active (or, current) builds, to be used for future releases, we may remove old versions of bundles according to the following guidelines.
  
*M6 - Friday March 16 
+
* Normally only 1 version of a bundle will be in active builds. Older bundle versions should be removed, since they would presumably never be used by other, active Eclipse projects. If projects or adopters still needed some older version, say for maintenance builds, they can get them from the older R-build repositories where they were last provided. Note: "versions" in this context, refers to differences in the major, minor, or service fields of the version. There is never a case where the same version, but different qualifiers would be in an active build. But, of course, it is common for the qualifier to change from one Orbit release to another, if fixes are made to the manifest, for example.
*M7  - Friday April 27
+
  
 +
* Why continue to have any bundle in "active builds" once it is built and deemed ready? The reason is to have the ability to have "integration builds" and "milestone builds" in order to get proper feedback and testing before we literally make it permanent in an R-build. There may well be improvements in the build process where only "one or two" bundles are built at a time and then go into the "I-build repository". In that case, the I-build repository would be considered the "active build". Plus, there is a desire to allow consumers, especially of "active builds" to refer to just one repository and "get everything they need" instead of having to refer to several repositories to to piece together their dependencies.
  
Note:
+
* There are a few exceptions to the above "only 1 version" rule:  
*Friday Mar. 23, 2006 - Eclipse Project 3.3M6
+
: - First and foremost, someone requests it, via bugzilla and gives good reason why they need an older version still.  
*Friday May 4, 2006 - Eclipse Project 3.3M7
+
: - For any known cases in the yearly Simultaneous Release where consumers already use more than one version -- again, for a good reason (such as the APIs changed in the newer version, and the project does not have the ability or need to move to the new API).
 +
: - There might be cases where the latest version of some package in Orbit depends on an older version of a package but that package itself can be used independently and someone wants to use a newer version of it.  
  
 +
* Any removal of an older version will normally be done by M3 of the current yearly release cycle (though RC1 is normally considered the "API freeze" date). This allows exceptions or mistakes to be corrected in time for the yearly release with no danger of "last minute" breakage. And M3 is the latest possible time (normally) ... committers should make an effort to do much earlier in a yearly release cycle.
  
 +
* Remember, older versions will stay in our SCM, as they are, forever. That is, the older versions are simply removed from the active builds ... never from SCM nor existing R-build repositories. This is partially so someone could find them if needed to investigate something, but also so we can easily add them back to active builds if needed.
  
=== Retention ===
+
* Removals should be documented in bugzilla ... similar to how additions are shoudl be documented in bugzilla.
  
The downloads area and bundles area are mirrored, so we will have a long term retention policy for multiple versions of bundles, to be sure it doesn't grow too large over the years. By policy, we will retain up to 3 versions of a bundle and after that, the older versions will be moved to the Eclipse archive area. These versions does not mean qualified versions, but means, for example, Xerces 2.8.0, 2.8.1, and 2.9.0. Once 2.9.1 was put in the repository, 2.8.0 would be archived. Eclipse Projects may request waivers to this policy if needed for some specific cases.
+
=== Comments ===
  
'''Comments from [[User:martin.oberhuber.windriver.com|Martin Oberhuber]] and Kim Moir: '''
+
'''Old Comments from [[Martin Oberhuber]] and Kim Moir: '''
 
Moved to the "discussion" tab
 
Moved to the "discussion" tab
  
  
 
[[Category:Orbit]]
 
[[Category:Orbit]]

Revision as of 11:46, 26 March 2019

Orbit itself does not have releases, per se, since the 3rd party jars that are bundled have already been released. But, we will still use the Eclipse Simultaneous Release rhythm to set deadlines for ourselves and promote and retain bundles.

An Orbit milestone date will be considered the same as the base Eclipse platform milestone date, since for anyone in a Simultaneous Release to use an Orbit Bundle, it would have to be ready (and final) at least a week or two before their milestone deadline.

Continuous Builds

Our continuous builds produce builds on the downloads page. Their purpose is for the committers to have something to see or download and confirm all is as they expect it to be. These builds are often short lived and can be deleted without notice.

Note that all new changes eventually trigger an integration (I) build that gets automatically promoted to the downloads page.

Milestone Release Process

  1. Log in with your committer account on https://ci.eclipse.org/orbit/
  2. Go to the orbit-recipes JIPP
    1. Click 'Build with Parameters'
    2. Change the BUILD_LABEL to S using the drop-down box, to indicate a stable build
    3. Make sure SIMREL_NAME is set to the name of the simultaneous release (eg. 2019-03) to which this build will contribute
    4. Leave everything else as-is, and click build
    5. Once the build succeeds, click the 'Keep this build forever' button, and add a description for the build (eg. 2019-03 M3).
    6. Also, take note of the timestamp used for the build at the bottom of the log file
  3. Modify the notes.php file to include a line containing the milestone build, and it's name (eg. $notes["S12345678901234"]="2019-03 M3"; )
  4. Go to the promote-to-downloads JIPP
    1. Click 'Build with Parameters'
    2. Change SRC_LOCATION to the path of the milestone build folder, relative to the root of the orbit folder and click build. For example, if the build was created at ' http://download.eclipse.org/tools/orbit/S-builds/S12345678901234/', then SRC_LOCATION would be S-builds/S12345678901234/
    3. The build should appear in the downloads page shortly
  5. Announce the release of the milestone build on the orbit-dev mailing list.
  6. Once you have made the announcement, the build is considered released. Be sure to update the referenceRepoBuild in releng/mavenparent/pom.xml property to reference the released build. This will ensure that new packages introduced in this (just announced) release have their timestamps frozen until further possible changes are introduced.

Milestones and Recommended ("Final") Bundles Area

Once per milestone, (roughly simultaneous with the platform's milestone), a rebuild will occur on the latest commit, and the earlier weekly builds may be deleted. Each Milestone Build will be retained until an Eclipse Simultaneous Release and then all deleted.

It was decided in June 12, 2007 status meeting to (still) have dated directories for the "final" builds, and was decided to call them "R-builds", which may sound like "Released", but is "Recommended" for Orbit, since Orbit does not have Releases in the Eclipse sense of that word. The bundles in "Recommended" builds will only be changed (re-created) if there are serious bugs found with them. Even then, any "Recommended" builds will be retained long term, such as for 2 years or so, so build scripts will not break and be re-creatable.

Milestones and Recommended Build "Notes" Column

On the main download page is a column labeled "Notes". While technically any "note" can be put in there, at a minimum for every "R-build" and "S-build" a note should be added for which Simultaneous Release the build was first recommended for.

Adding notes to the file is a matter of "hand editing" the "notes.php" file on the download server. It is under

.../tools/orbit/downloads/

and new entries are added, by adding new array entries, which are indexed by the "display name" of the download. For example, if existing file started with the following:

<?php

$notes = array();

$notes["R20140525021250"]="Luna, Luna SR1";
$notes["R20140114142710"]="Kepler SR2";

then the next R-build was for Mars, and named R201506011000, and no new R-build for Luna SR2, that file would end up starting with:

<?php

$notes = array();

$notes["R20150601100000"]="Mars";
$notes["R20140525021250"]="Luna, Luna SR1, Luna SR2";
$notes["R20140114142710"]="Kepler SR2";

This file, and others are stored in module org.eclipse.orbit.releng.downloadsites but there is no automatic update or anything from those files, to download server.

Milestone dates

The Orbit milestones dates will be a -1 delivery in Simultaneous Releases, to allow all projects to pick up prereqs (even the Platform, the 0 delivery).

Build Retention

Milestone builds will be retained until the Recommend build is produced.

Recommended builds will be kept forever, the most recent one(s) on 'download.eclipse.org' but older ones will be moved to 'archive.eclipse.org' (which is not mirrored) The old, archived builds should rarely be needed, used only be used if someone needed to re-create some old build which was based upon it, such as for long term maintenance.

Bundle Retention in active builds

It is our Orbit project's policy that once a bundle is delivered in an R-build, it will be retained forever in that R-build (or its repository). But, in active (or, current) builds, to be used for future releases, we may remove old versions of bundles according to the following guidelines.

  • Normally only 1 version of a bundle will be in active builds. Older bundle versions should be removed, since they would presumably never be used by other, active Eclipse projects. If projects or adopters still needed some older version, say for maintenance builds, they can get them from the older R-build repositories where they were last provided. Note: "versions" in this context, refers to differences in the major, minor, or service fields of the version. There is never a case where the same version, but different qualifiers would be in an active build. But, of course, it is common for the qualifier to change from one Orbit release to another, if fixes are made to the manifest, for example.
  • Why continue to have any bundle in "active builds" once it is built and deemed ready? The reason is to have the ability to have "integration builds" and "milestone builds" in order to get proper feedback and testing before we literally make it permanent in an R-build. There may well be improvements in the build process where only "one or two" bundles are built at a time and then go into the "I-build repository". In that case, the I-build repository would be considered the "active build". Plus, there is a desire to allow consumers, especially of "active builds" to refer to just one repository and "get everything they need" instead of having to refer to several repositories to to piece together their dependencies.
  • There are a few exceptions to the above "only 1 version" rule:
- First and foremost, someone requests it, via bugzilla and gives good reason why they need an older version still.
- For any known cases in the yearly Simultaneous Release where consumers already use more than one version -- again, for a good reason (such as the APIs changed in the newer version, and the project does not have the ability or need to move to the new API).
- There might be cases where the latest version of some package in Orbit depends on an older version of a package but that package itself can be used independently and someone wants to use a newer version of it.
  • Any removal of an older version will normally be done by M3 of the current yearly release cycle (though RC1 is normally considered the "API freeze" date). This allows exceptions or mistakes to be corrected in time for the yearly release with no danger of "last minute" breakage. And M3 is the latest possible time (normally) ... committers should make an effort to do much earlier in a yearly release cycle.
  • Remember, older versions will stay in our SCM, as they are, forever. That is, the older versions are simply removed from the active builds ... never from SCM nor existing R-build repositories. This is partially so someone could find them if needed to investigate something, but also so we can easily add them back to active builds if needed.
  • Removals should be documented in bugzilla ... similar to how additions are shoudl be documented in bugzilla.

Comments

Old Comments from Martin Oberhuber and Kim Moir:

Moved to the "discussion" tab

Copyright © Eclipse Foundation, Inc. All Rights Reserved.