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"

(incorporated some comments and improved wording)
Line 3: Line 3:
 
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 will be considered the same as the base Eclipse platform. This is a statement of time, as opposed to content, since for anyone else in the 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.  
  
Our continuous builds produce bundles ("builds") in the [http://download.eclipse.org/tools/orbit/committers/ committers area].
+
=== Continuous Builds ===
 +
 
 +
Our continuous builds produce builds in the [http://download.eclipse.org/tools/orbit/committers/ committers area].
 
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 ===
  
 
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.  
 
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.  
  
Once per milestone, (roughly simultaneous with the platform's milestone), the bundles from the latest weekly build will be copied to the [http://download.eclipse.org/tools/orbit/downloads/bundles bundles area]. This is to be considered the final home for the bundles added here. That is, these "milestone" bundles should not normally have to be re-built. In case they do, they will have different qualifiers in the fourth field. As a matter of policy, we will retain up to 3 qualified versions of the same bundle. (And, we anticipate it being very rare to hit that limit).  
+
=== Milestones and 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/bundles bundles area]. 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.
 +
 
 +
'''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.  
  
'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.
+
=== Retention ===
  
The downloads area and bundles area are mirrored, so we will have a retention policy for bundles in general, to be sure it doesn't grow too large over the years. By policy, we will retain up to 3 versions of some bundle and after that, the older versions will be moved to the archive area. These "versions" do not include 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.
+
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 from [[User:martin.oberhuber.windriver.com|Martin Oberhuber]] and Kim Moir: ===
+
'''Comments from [[User:martin.oberhuber.windriver.com|Martin Oberhuber]] and Kim Moir: '''
 
Moved to the "discussion" tab
 
Moved to the "discussion" tab

Revision as of 20:34, 2 February 2007

= UNDER REVIEW =

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 in the committers area. 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

Once per week, currently by Monday noon (Eastern time), the latest continuous build will be copied over to the downloads area. These are similar or analogous to weekly Integration Builds, and will be retained in place until the Milestone release.

Milestones and 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 bundles area. 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.

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.

Retention

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 from Martin Oberhuber and Kim Moir: Moved to the "discussion" tab

Back to the top