Jump to: navigation, search

Difference between revisions of "WTP/Retention Policy"

< WTP
(Builds on update sites)
(Features in update site repository)
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
== Retention Policy for WTP builds ==
 
== Retention Policy for WTP builds ==
 +
 +
=== Code in CVS ===
 +
 +
Any code that was included in a Release, is left in CVS forever. The version a module that is included in a release will typically have a convenience version tag on the module, such as "R3_1_2", but the releng map files are the definitive authority on what was included in a release. The map files are given convenience tags, such as "R3_1_2", but they are also tagged each build, if there is ever any doubt. Those 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 ===
 
=== Distributions in zip files ===
Line 16: Line 20:
 
The update site repository will be treated as a persistent repository of content. (From WTP 3.1.1, onward.) Once something is installable from a release repository URL, it will always be installable from that repository URL. This policy technically, currently applies to only WTP, since Eclipse Foundation as a whole currently does not have an Eclipse-wide policy, but its expected our prerequisite projects will do similar (and beginning with Galileo SR1, all Simultaneous Release projects will be persisted, even if the Project does not manage it themselves). Note that the efficiency of installing old releases may not be maintained. That is, they would be expected to be slower, as eventually old artifacts will be moved to the eclipse archives, and no longer mirrored. Also, the "categories" that display the features in Eclipse 'Install New Software' dialog will change over time, but the underlying features and bundles will be there, even if not displayed in a category.
 
The update site repository will be treated as a persistent repository of content. (From WTP 3.1.1, onward.) Once something is installable from a release repository URL, it will always be installable from that repository URL. This policy technically, currently applies to only WTP, since Eclipse Foundation as a whole currently does not have an Eclipse-wide policy, but its expected our prerequisite projects will do similar (and beginning with Galileo SR1, all Simultaneous Release projects will be persisted, even if the Project does not manage it themselves). Note that the efficiency of installing old releases may not be maintained. That is, they would be expected to be slower, as eventually old artifacts will be moved to the eclipse archives, and no longer mirrored. Also, the "categories" that display the features in Eclipse 'Install New Software' dialog will change over time, but the underlying features and bundles will be there, even if not displayed in a category.
  
=== Zip files for patches or update sites ===
+
Starting with Helios, 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,
  
The [http://download.eclipse.org/webtools/patches/ patch builds] are not retained.  
+
http://download.eclipse.org/webtools/repository/helios, or (for the next release)
 +
http://download.eclipse.org/webtools/repository/indigo
  
Granted, some of them have been around a long time, but 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.
+
Under the covers, we plan to have a directory structure that allows easy composites sites to be made, such as
  
=== Complicating Situations ===
+
  repository/helios/sr0
 +
  repository/helios/sr1
 +
  repository/helios/sr2
 +
  repository/indigo/sr0
 +
  repository/indigo/sr2
 +
  repository/indigo/sr3
  
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 could 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 in general was depending it.
+
but only the high-level release-specific URL can be counted on as "api-like" and persistent. The subdirectories will vary and not necessarily be persistent.
 +
See also {{bug|291637}} to monitor how naming schemes may evolve.
  
=== What if these policies don't work for you? ===  
+
=== Zip files for patches or update sites ===
  
Just ask. Open a bug or post a note to wtp-releng and request what you need left on the update site or download pages.  
+
The [http://download.eclipse.org/webtools/patches/ patch builds] are not retained.  
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.  
+
Granted, some of them have been around a long time, but 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.  
 
+
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, let us know if really required.  
+
  
 +
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.
  
 +
=== Complicating Situations ===
  
 +
The above rules apply to each sub-project within WTP, primarily for the yearly Simultaneous Release. A project can have an off cycle release, but essentially the same rules apply, for any formal release.
  
 +
=== 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.
 +
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 in releng if something special is required.
  
  
  
 
[[Category:Eclipse Web Tools Platform Project]][[Category:Process and Policies| ]]
 
[[Category:Eclipse Web Tools Platform Project]][[Category:Process and Policies| ]]

Latest revision as of 14:18, 28 May 2010

Retention Policy for WTP builds

Code in CVS

Any code that was included in a Release, is left in CVS forever. The version a module that is included in a release will typically have a convenience version tag on the module, such as "R3_1_2", but the releng map files are the definitive authority on what was included in a release. The map files are given convenience tags, such as "R3_1_2", but they are also tagged each build, if there is ever any doubt. Those 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 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

Changed beginning with 3.1.1 and 3.1.2. 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.

The update site repository will be treated as a persistent repository of content. (From WTP 3.1.1, onward.) Once something is installable from a release repository URL, it will always be installable from that repository URL. This policy technically, currently applies to only WTP, since Eclipse Foundation as a whole currently does not have an Eclipse-wide policy, but its expected our prerequisite projects will do similar (and beginning with Galileo SR1, all Simultaneous Release projects will be persisted, even if the Project does not manage it themselves). Note that the efficiency of installing old releases may not be maintained. That is, they would be expected to be slower, as eventually old artifacts will be moved to the eclipse archives, and no longer mirrored. Also, the "categories" that display the features in Eclipse 'Install New Software' dialog will change over time, but the underlying features and bundles will be there, even if not displayed in a category.

Starting with Helios, 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/webtools/repository/helios, or (for the next release)
http://download.eclipse.org/webtools/repository/indigo 


Under the covers, we plan to have a directory structure that allows easy composites sites to be made, such as

  repository/helios/sr0
  repository/helios/sr1
  repository/helios/sr2
  repository/indigo/sr0
  repository/indigo/sr2
  repository/indigo/sr3

but only the high-level release-specific URL can be counted on as "api-like" and persistent. The subdirectories will vary and not necessarily be persistent. See also bug 291637 to monitor how naming schemes may evolve.

Zip files for patches or update sites

The patch builds are not retained.

Granted, some of them have been around a long time, but 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.

Complicating Situations

The above rules apply to each sub-project within WTP, primarily for the yearly Simultaneous Release. A project can have an off cycle release, but essentially the same rules apply, for any formal release.

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. 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 in releng if something special is required.