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 "WTP/Retention Policy"

< WTP
(document retention policy)
 
(Builds on update sites)
Line 12: Line 12:
  
 
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 "3.0.3", the "3.0.2" version won't be on the update site any longer. So, someone with "3.0.0" installed could update to "3.0.3", but they could no longer update only to "3.0.2", once 3.0.3 was released.  
 
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 "3.0.3", the "3.0.2" version won't be on the update site any longer. So, someone with "3.0.0" installed could update to "3.0.3", but they could no longer update only to "3.0.2", once 3.0.3 was released.  
 +
 +
=== Complicating Situations ===
 +
 +
The above rules apply to each sub-project within WTP, so occasionally, a project can have an off cycle release. In this case, "older" releases of a project would be kept on an update site, if needed by other projects within WTP. For example, Dali might come out with a "2.1.1", and the "2.1.0" would be removed, but Dali "2.0.4" would also be kept, since WTP 3.0.4 was depending it.
 +
 +
=== What if these policies don't work for you? ===
 +
 +
Just ask. Open a bug or post a note to wtp-releng and request what you need left on update site.
 +
This might happen, for example, if an adopter built a product on, say, "3.0.2" and they are unable to move up or test to the latest "3.0.4" until some future date, so that adopter might need to direct their users to update specifically to "3.0.2".
 +
 +
Even if a problem is found in retrospect, update sites can usually be restored to some previous state, since we have the basic data duplicated in the archive system and cvs.
 +
 +
In other words, we are glad to be accommodating, but don't want accommodate every hypothetical combination, since it's more work for us and higher disk and transmission load on the Eclipse mirroring system. So, let us know.
 +
 +
 +
 +
 +
 +
 +
  
  
 
[[Category:Eclipse Web Tools Platform Project]][[Category:Process and Policies| ]]
 
[[Category:Eclipse Web Tools Platform Project]][[Category:Process and Policies| ]]

Revision as of 00:23, 9 April 2009

Retention Policy for WTP builds

Builds in zip files

Formal releases are kept forever, but only the most recent release is kept on the main download page. Other, older build can be found on the eclipse 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 builds are kept until the milestone is available, and then deleted.

Builds on update sites

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 "3.0.3", the "3.0.2" version won't be on the update site any longer. So, someone with "3.0.0" installed could update to "3.0.3", but they could no longer update only to "3.0.2", once 3.0.3 was released.

Complicating Situations

The above rules apply to each sub-project within WTP, so occasionally, a project can have an off cycle release. In this case, "older" releases of a project would be kept on an update site, if needed by other projects within WTP. For example, Dali might come out with a "2.1.1", and the "2.1.0" would be removed, but Dali "2.0.4" would also be kept, since WTP 3.0.4 was depending it.

What if these policies don't work for you?

Just ask. Open a bug or post a note to wtp-releng and request what you need left on update site. This might happen, for example, if an adopter built a product on, say, "3.0.2" and they are unable to move up or test to the latest "3.0.4" until some future date, so that adopter might need to direct their users to update specifically to "3.0.2".

Even if a problem is found in retrospect, update sites can usually be restored to some previous state, since we have the basic data duplicated in the archive system and cvs.

In other words, we are glad to be accommodating, but don't want accommodate every hypothetical combination, since it's more work for us and higher disk and transmission load on the Eclipse mirroring system. So, let us know.

Back to the top