Difference between revisions of "MoDisco/Retention Policy"

From Eclipsepedia

Jump to: navigation, search
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== Retention Policy for MoDisco builds (Draft) ==
 
== Retention Policy for MoDisco builds (Draft) ==
 +
 +
=== Code in SVN ===
 +
 +
Any code that was included in a Release, is left in SVN 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_1_2".
  
 
=== Distributions in zip files ===
 
=== Distributions in zip files ===
Line 11: Line 15:
 
=== Features in update site repository ===  
 
=== Features in update site repository ===  
  
The update site repository will be treated as a persistent repository of content. 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 it's 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. Once something is installable from a release repository URL, it will always be installable from that repository URL. Note that the efficiency of installing old releases may not be maintained. 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.
  
 
=== What if these policies don't work for you? ===  
 
=== 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.  
+
Just ask. Open a bug 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.  
 
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.
+
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.
 +
 
 +
{{MoDisco}}
 +
[[Category:MoDisco]]

Latest revision as of 09:07, 24 February 2011

Contents

[edit] Retention Policy for MoDisco builds (Draft)

[edit] Code in SVN

Any code that was included in a Release, is left in SVN 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_1_2".

[edit] 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 release, 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.

[edit] Features in update site repository

The update site repository will be treated as a persistent repository of content. Once something is installable from a release repository URL, it will always be installable from that repository URL. Note that the efficiency of installing old releases may not be maintained. 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.

[edit] What if these policies don't work for you?

Just ask. Open a bug 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.


MoDisco
Components Infrastructure: KDM · SMM · GASTM · Model Browser · Discovery Manager · MoDisco Workflow · Query Manager · Facet Manager · Metrics Visualization Builder · KDM Source Extension
Technologies: Java · JEE · EjbJar · WebApp · XML
Use Cases: Simple Transformation Chain · Model Filter
Help Installation · SVN
Project API Policy · Retention Policy · Project Plan · metrics · Accessibility Guidelines · Capabilities Disablement