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 "Papyrus/Papyrus Developer Guide/Release Process: How To"

(Updating the pom-xxx.xml)
(D-day of the GA release)
 
(194 intermediate revisions by 7 users not shown)
Line 1: Line 1:
The Papyrus project is built using [https://eclipse.org/tycho/ Tycho] with this releng project:
+
The Papyrus project is built using [https://eclipse.org/tycho/ Tycho] and orchestrated by this [https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/releng releng project].
[https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/releng Releng]  
+
 
 +
The release engineer must have:
 +
* Unrestricted shell access to build.eclipse.org (log a bug to Community/Server to obtain SSH access: see [http://bugs.eclipse.org/bugs/show_bug.cgi?id=366699 bug 366699]). To know if your shell is restricted, try to execute linux commands and see if you get disconnected.
 +
* The rights to launch jobs on the integration platform : https://hudson.eclipse.org/hudson/ (should come with the Papyrus committer rights, but can be granted by the platform admin)
 +
* Write access to /home/data/httpd/download.eclipse.org/modeling/mdt/papyrus (should come with the Papyrus committer rights)
 +
* Subscribed to the [https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev cross-project-issues-dev] mailing list, on which discussions relevant to the releng activities take place
 +
* Be aware of the release plan and the step he needs to contribute to, +3 for papyrus, which can be found [https://wiki.eclipse.org/SimRel/Simultaneous_Release_Cycle_FAQ#What_is_the_schedule_of_the_next_releases_.3F here]
 +
 
 +
 
  
 
== Hudson Jobs ==
 
== Hudson Jobs ==
The Papyrus builds are started from Hudson. The following jobs on the [https://hudson.eclipse.org/papyrus/view/Mars/ Mars branch] exist currently.
+
 
 +
The Papyrus builds are started from Jenkins. The following jobs on the [[https://ci.eclipse.org/papyrus/view/Master/ | Master branch]] exist currently.
 
There should always be the following jobs on each release branch:
 
There should always be the following jobs on each release branch:
 
* papyrus-Master : builds the main plug-ins of Papyrus
 
* papyrus-Master : builds the main plug-ins of Papyrus
Line 9: Line 18:
 
* papyrus-Master-Tests : builds the tests for the main plugins of Papyrus
 
* papyrus-Master-Tests : builds the tests for the main plugins of Papyrus
 
* papyrus-Master-Tests-Failures : tests identified as failed, not regressions, kept to keep the main tests clean and without spams
 
* papyrus-Master-Tests-Failures : tests identified as failed, not regressions, kept to keep the main tests clean and without spams
* papyrus-Master-Developer : developer tools, such as debug views in eclipse, papyrus diagram code generator and building tools
+
* papyrus-Master-Toolsmiths : developer tools, such as debug views in eclipse, papyrus diagram code generator, building and customization tools
* papyrus-Master-Extra : builds the "extra" plug-ins of Papyrus
+
* papyrus-Master-Extra-Tests : builds the tests for the "extra" plug-ins
+
  
 
See all the currently defined Papyrus jobs on the page :  
 
See all the currently defined Papyrus jobs on the page :  
<nowiki>https://hudson.eclipse.org/papyrus/view/<Eclipse version></nowiki>
+
<nowiki>https://hudson.eclipse.org/papyrus/view/<release_name></nowiki>
 
You can add the name of the eclipse release to find the associated jobs, i.e. Mars, Luna...
 
You can add the name of the eclipse release to find the associated jobs, i.e. Mars, Luna...
  
== What is built? ==
 
  
Taking the example of "papyrus-Master", we use the releng's pom.xml files:
+
== Before starting a build ==
* top-pom-main.xml
+
* top-pom-main-tests.xml
+
* top-pom-extras.xml
+
* top-pom-extra-tests.xml
+
  
These files must include all features, plugins and update sites that must be built, either directly or indirectly.
+
=== General Information ===
  
The pom-xxx.xml file also specifies how to get the plug-ins and features that are to be built and specifies the update sites from which to retrieve the binary dependencies from the dependent projects.
+
Unlike Nightlies, Milestone builds, contributed to the release train, are publicly available to anyone downloading the latest Developer Build of Eclipse. This implies a few differences in terms of quality of the release:
  
=== Updating the pom-xxx.xml ===
+
* All artifacts must be signed, using the Eclipse Certificate
The files reflects the dependencies on the other projects. So, it must be updated at least before each milestone, to make sure that the code that is built works with the latest versions of all the dependencies.
+
* The build must be as stable as possible. Especially, any Blocker or Critical bug must be fixed before the release
 +
* All License files must be available and up-to-date
 +
* All plug-in metadata must be defined (Especially, bundle name, bundle vendor and feature description)
 +
* The Papyrus update site must contain everything that is not already contained in the Eclipse Simrel repository (i.e. any plug-in from an Eclipse Project that is not in the release train)
  
The easiest way to update the dependencies is to copy them from the aggregation build model, which all projects must fill in with the correct reference to their update site(s) and feature(s).
 
  
This model is in a project with the release name on the Eclipse Git:
+
=== Must Have ===
* git://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git
+
  
[[File:cloneSimrelRepo.png|center|800px|thumb|'''Clone the simrel repository''']]
+
As a rule of thumbs, before starting your build journey it is preferable to have a clean install of the Eclipse package you want to test your build against and install the necessary tools and dependencies.
 +
You will need to install the following (some may require you to fetch previously build components from other projects that contributes earlier in the train):
  
 +
Use an Eclipse with Papyrus developer tools installed from the following update site, eg for the XYZ version:
 +
<nowiki>https://hudson.eclipse.org/papyrus/job/Papyrus-XYZ-Toolsmiths/lastSuccessfulBuild/artifact/repository</nowiki>
  
[[File:importBuildToolsAfterClone.png|center|600px|thumb|'''Import the simrel project''']]
+
This install might need you to posses the following papyrus nightly build address in your available update sites as the developper tools depends on some plugins contained in it:
 +
<nowiki>https://hudson.eclipse.org/papyrus/job/Papyrus-XYZ/lastSuccessfulBuild/artifact/repository/</nowiki> 
 +
Install the tpd updater tool from this [https://github.com/mbarbero/fr.obeo.releng.targetplatform Github project] from this update site:
 +
<nowiki>https://dl.bintray.com/mbarbero/fr.obeo.releng.targetplatform/latest</nowiki> (4.1.0 and before)
 +
<nowiki>http://download.eclipse.org/cbi/tpd/**</nowiki> (4.2.0 and after)
  
 +
Papyrus (a clean clone is also useful to have for the builds as it will be much less susceptible to be corrupted by your daily work) up to date:
 +
<nowiki>git://git.eclipse.org/gitroot/papyrus/org.eclipse.papyrus.git</nowiki>
 +
Simrel on which you will later post your updated aggregator file:
 +
<nowiki>git://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git</nowiki>
  
There is a tool that copies most of the information automatically in this plug-in:
+
Another should have, not mandatory but useful, is the b3 aggregator editor to get a clearer view of the aggregator files in the simrel repository:
* (see the [https://hudson.eclipse.org/papyrus/view/Mars/job/Papyrus-Master-Developer/lastSuccessfulBuild/artifact/releng/dev/target/repository/ Papyrus developer tools - Mars])
+
  https://wiki.eclipse.org/Eclipse_b3/aggregator/manual#Installation
* (see the [https://hudson.eclipse.org/papyrus/view/Mars/job/Papyrus-Master-Developer/lastSuccessfulBuild/artifact/releng/dev/target/repository/plugins/ plugins contained in the previous link - Mars])
+
Those tools are dependant to the <Version> linked to the build, hence there are tools for Mars, tools for Luna,...
+
  
  
'''Warning''': don't forget to pull the last changes and check for recent updates in order to build the correct state and verify that the branch built is the correct one (master or <Eclipse version>_maintenance, e.g. Luna_maintenance)
+
== Update Papyrus Dependencies and References ==
  
 +
You need to [[Papyrus Developer Guide/Release Process: How To/Update Papyrus Dependencies | prepare the content]] for the next release by checking that everything depends on the latest releases of the train and that the versions are all up to date.
  
[[File:updateRepository.png|center|600px|thumb|'''update the local repository''']]
 
  
 +
== Publish The artifacts ==
  
[[File:CheckingOutTheRelengTools2.png|center|1000px|thumb|'''Install the releng tools''']]
+
When the produced artifacts are successfully produced by the Jenkins job and that you tested their installation and functionalities you will be able to [[Papyrus Developer Guide/Release Process: How To/Publish Papyrus Artifacts | publish them]].
  
  
[[File:updateDependencies.png|center|600px|thumb|'''Update the dependencies of the selected poms''']]
+
=== Checking the reports ===
  
 +
At the end of each milestone you will need to check the installation from the staging update site and check the reports generated by the simrel aggregation job.
  
[[File:chooseBuildModel.png|center|600px|thumb|'''Choose the build model from the simrel project''']]
+
The simrel reports are available at :
 +
* <nowiki>https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/**BuildNumber**/artifact/target/repository/final/buildInfo/reporeports/index.html</nowiki>
  
 +
And the simrel/staging update site at :
 +
* http://download.eclipse.org/releases/staging (Master)
 +
* http://download.eclipse.org/releases/maintenance (Maintenance)
  
[[File:simrelBuildModel.png|center|600px|thumb|'''The simrel model used to update the dependencies''']]
+
== Preparing the GA release ==
  
 +
When the final artifacts have been contributed and each milestones have been tagged in the repository, it is time to [[Papyrus Developer Guide/Release Process: How To/Prepare the GA Release | prepare the for the GA release]].
  
A few dependencies are not in the aggregation build model though, so they must be updated manually:
 
* '''Orbit''' : you can find the latest version listed on : http://download.eclipse.org/tools/orbit/downloads/
 
  
 +
== D-day of the GA release ==
  
==== Finding dependencies ====
+
Keep in mind that depending on the date of your release review, you might have an official release day after the GA of the built Eclipse Package.  
If you don't know where a particular plug-in or feature is located, the easiest way to find it is to search the Eclipse download area using "find" on the ssh of build.eclipse.org.
+
For example, to look for "org.eclipse.emf.compare" :
+
find /home/data/httpd/download.eclipse.org/modeling/emf/ -name 'org.eclipse.emf.compare_*'
+
  
==== Push ====
+
When the day comes however (meaning that the release is reviewed and the Eclipse has officialy declared the GA on the cross-project mailing list), you will have to:
When pushing to the papyrus' gerrit you should use the standardized message :
+
# Run the [https://ci.eclipse.org/papyrus/view/MasterRelease/ GA publishing script],
* [Releng] Update dependencies for <Eclipse Version> <Milestone>
+
# Amend the composites in the release folder to point to the new release and remove the dummy index.html file,
e.g. [Releng] Update dependencies for Mars M7
+
# Merge the prepared patches for the Website and your new development branch,
 +
# Update the simrel file.
  
== How to start a build? ==
+
Finally, do not forget to remind the Papyrus Lead, again annoy as needed, to communicate about the release:
 +
# mail in the mailing list dev,
 +
# post on the forum.
  
=== Automatically ===
 
  
* Builds, master and maintenances, are run automatically every night, every day and each hour if there has been a commit.
+
This will end the release process. Good job! :)
  
=== Manually ===
+
== Maintenance ==
  
Only committers in the Papyrus project can launch Papyrus build jobs from Hudson.
+
After a while you will need to move some milestones and releases to the archives, meaning moving them from downloads.eclipse.org to archive.eclipse.org that is not mirrored. It is a good practice as it will save time, space and resources server-wise.
 +
The corresponding paths on the server are:
 +
/home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/downloads/drops/
 +
/home/data/httpd/archive.eclipse.org/modeling/mdt/papyrus/downloads/drops/
  
Go to the wanted page if you want to launch a selected build, e.g. https://hudson.eclipse.org/papyrus/view/Mars/
+
This can be done manually, until a better solution has been implemented, but be aware of the following guidelines:
 
+
* d.e.o - downloads/drops: keep the last 2 or 3 releases depending on the span you want to cover and that the removed content has been copied in archive of course
 
+
* d.e.o - updates/releases: everything here should be kept. Very old releases could be moved to the archive server depending on usage.
== Build parameters ==
+
* d.e.o - updates/milestones: this can be handled more loosely, but a good rule of thumb is to keep the last 2 or 3 milestones of what you want to keep in order to  
Hudson builds expect these parameters:
+
allow eclipse to 'revert to previous installation' if needed.
* BUILD_ALIAS : the name of the release (0.9.0, 1.1.0M6, etc.); leave it blank for nightly and integration builds
+
* a.e.o - downloads/drops: this '''needs''' to contain '''every''' releases published. There are no constraint on how recent or old they need to be so if you are not sure you will remember you can copy the release as soon as its out ;). You can also put milestones in here but that is not required.
* SIGN : whether to sign the update site (can take up to an hour on the Eclipse build server); mandatory for all builds except nightlies
+
 
+
 
+
[[File:buildParameters.png|center|1000px|thumb|'''Enter the build parameters''']]
+
 
+
 
+
Then:
+
* In Hudson, click on '''Build Now''', change the build parameters as needed (see [[#Build parameters]]), and click on '''Build'''.
+
* You can then click on the job name in the ''Build History'' section in the left column, and then on '''Console Output''', to follow build progress in real time.
+
 
+
== How to publish a build? ==
+
 
+
=== Automatically ===
+
Successful Nightly builds are automatically published to :
+
* http://download.eclipse.org/modeling/mdt/papyrus/updates/nightly/mars/
+
 
+
 
+
=== With the script ===
+
 
+
To publish a milestone or release from a build, you can use the manualPromote.sh for Luna, and manualPromote-mars.sh for Mars, script on: '''/opt/public/modeling/mdt/papyrus/manualPromote.sh'''
+
Start this script, and fill in the parameters in the interactive script.
+
 
+
For example:
+
 
+
$ cd /opt/public/modeling/mdt/papyrus/
+
$ ./manualPromote.sh
+
-------------------- user parameters --------------------
+
mainBuildNumber (the number of the "papyrus-trunk-nightly" Hudson build from which to publish the main Papyrus plug-ins):
+
? 519
+
extrasBuildNumber (the number of the "papyrus-trunk-extra-nightly" Hudson build from which to publish the extra Papyrus plug-ins, or 0 to not publish):
+
? 43
+
testsBuildNumber (the number of the "papyrus-trunk-nightly-tests" Hudson build from which to publish the test results, or 0 to not publish):
+
? 93
+
version (e.g. "0.9.0"):
+
? 0.9.0
+
updateSite (e.g. "nightly/juno", "milestones/0.9/M5", "releases/indigo/0.8.1") :
+
? milestones/0.9/M5
+
Are you sure you want to publish with these parameters (yes|no)?
+
? yes
+
 
+
In the previous example, the script will:
+
* publish the main Papyrus plug-ins from papyrus-trunk-nightly build #519 to the Papyrus download in "drops/0.9.0" and the update site in "milestones/0.9/M5/main"
+
* publish the extra plug-ins from papyrus-trunk-extra-nightly build #43 to the Papyrus download in "drops/0.9.0" in the same build folder as the main build, and the update site in "milestones/0.9/M5/extra"
+
* publish the test results from papyrus-trunk-nightly-tests build #93 to the Papyrus download in "drops/0.9.0" in the same build folder as the main build
+
* make "milestones/0.9/M5" a composite update site, which contains "milestones/0.9/M5/main" and "milestones/0.9/M5/extra"
+
* enable p2 download statistics both on "milestones/0.9/M5/main" and "milestones/0.9/M5/extra"
+
* set the correct linux access rights on the new folders
+
 
+
Once the script is done, all you have left to do is to:
+
* [[#Tagging|Tag the build]]
+
* [[#Simultaneous_Release|update the aggregation model]] if this build must be part of the simultaneous release
+
 
+
 
+
=== Manually ===
+
Stable builds are not automatically published. They should be first tested internally before publishing. For example, to publish the 1.1.0M6 milestone build:
+
* '''First''',  the build is on the update site nightly http://download.eclipse.org/modeling/mdt/papyrus/updates/nightly/mars/
+
* '''Then''', install the build and test  it manually
+
* '''Then''', publish it using the script manualPromote.sh
+
 
+
 
+
Add a new update site with the new build to the parent composite (~/downloads/modeling/mdt/papyrus/updates/milestones/1.1/):
+
* '''update''' both the <code>compositeContent.xml</code> and <code>compositeArtifacts.xml</code> files of the update site (that are located in the parent of the folder to which you extracted the update site) to add a reference to your newly added update site
+
** set the value of p2.timestamp to the result of "<code>date +%s000</code>"
+
** increase the "size" attribute of the children element
+
** add a "child" element inside the "children" element with a "location" set to the name of the folder (e.g "M6")
+
* '''Check''' that the new build appears on [http://www.eclipse.org/papyrus/downloads/ http://www.eclipse.org/papyrus/downloads/].
+
Builds can be hidden from this page before a release by modifying <code>downloads-scripts.php</code> in <code>/downloads/</code> on [git://git.eclipse.org/gitroot/www.eclipse.org/papyrus.git git://git.eclipse.org/gitroot/www.eclipse.org/papyrus.git]
+
* [[#Tagging|Tag the build]]
+
 
+
 
+
=== Simultaneous Release ===
+
If the build must be part of the simultaneous release, you must also:
+
* Use the [http://wiki.eclipse.org/Eclipse_b3/aggregator/manual B3 Aggregator] (or a text editor if the modification is trivial) and push to the simrel's gerrit which path is : ssh://username@git.eclipse.org:29418/simrel/org.eclipse.simrel.build.git)
+
Usually, the only thing to change is the location (for example "milestones/1.1/M6/main"):
+
<repositories location="http://download.eclipse.org/modeling/mdt/papyrus/updates/milestones/1.1/M6/main" description="Papyrus">
+
 
+
[[File:UpdatePapyrusContributionToMarsM7.png|center|1300px|thumb|'''Previous composite address''']]
+
 
+
 
+
[[File:UpdatePapyrusContributionToMarsRC1.png|center|1300px|thumb|'''Updated composite address''']]
+
 
+
 
+
== Tagging ==
+
Releases should have a tag like '''0.9.0''', and milestones should have a tag like '''0.9.0_M7'''.
+
 
+
== Checking ==
+
 
+
=== Check simrel reports ===
+
After the simrel build, you can check the reports at :
+
* https://hudson.eclipse.org/simrel/job/simrel.build.repoReportsAndTests/lastSuccessfulBuild/artifact/test-report/reports-staging/reporeports/index.html
+
 
+
 
+
=== Check installations ===
+
Check installation from the simrel/staging update site at :
+
* http://download.eclipse.org/releases/staging (Master)
+
* http://download.eclipse.org/releases/maintenance (Maintenance)
+

Latest revision as of 10:38, 10 July 2020

The Papyrus project is built using Tycho and orchestrated by this releng project.

The release engineer must have:

  • Unrestricted shell access to build.eclipse.org (log a bug to Community/Server to obtain SSH access: see bug 366699). To know if your shell is restricted, try to execute linux commands and see if you get disconnected.
  • The rights to launch jobs on the integration platform : https://hudson.eclipse.org/hudson/ (should come with the Papyrus committer rights, but can be granted by the platform admin)
  • Write access to /home/data/httpd/download.eclipse.org/modeling/mdt/papyrus (should come with the Papyrus committer rights)
  • Subscribed to the cross-project-issues-dev mailing list, on which discussions relevant to the releng activities take place
  • Be aware of the release plan and the step he needs to contribute to, +3 for papyrus, which can be found here


Hudson Jobs

The Papyrus builds are started from Jenkins. The following jobs on the [| Master branch] exist currently. There should always be the following jobs on each release branch:

  • papyrus-Master : builds the main plug-ins of Papyrus
  • papyrus-Master-Analysis : static analysis of the code, i.e. findBugs, sonar...
  • papyrus-Master-Tests : builds the tests for the main plugins of Papyrus
  • papyrus-Master-Tests-Failures : tests identified as failed, not regressions, kept to keep the main tests clean and without spams
  • papyrus-Master-Toolsmiths : developer tools, such as debug views in eclipse, papyrus diagram code generator, building and customization tools

See all the currently defined Papyrus jobs on the page : https://hudson.eclipse.org/papyrus/view/<release_name> You can add the name of the eclipse release to find the associated jobs, i.e. Mars, Luna...


Before starting a build

General Information

Unlike Nightlies, Milestone builds, contributed to the release train, are publicly available to anyone downloading the latest Developer Build of Eclipse. This implies a few differences in terms of quality of the release:

  • All artifacts must be signed, using the Eclipse Certificate
  • The build must be as stable as possible. Especially, any Blocker or Critical bug must be fixed before the release
  • All License files must be available and up-to-date
  • All plug-in metadata must be defined (Especially, bundle name, bundle vendor and feature description)
  • The Papyrus update site must contain everything that is not already contained in the Eclipse Simrel repository (i.e. any plug-in from an Eclipse Project that is not in the release train)


Must Have

As a rule of thumbs, before starting your build journey it is preferable to have a clean install of the Eclipse package you want to test your build against and install the necessary tools and dependencies. You will need to install the following (some may require you to fetch previously build components from other projects that contributes earlier in the train):

Use an Eclipse with Papyrus developer tools installed from the following update site, eg for the XYZ version:

https://hudson.eclipse.org/papyrus/job/Papyrus-XYZ-Toolsmiths/lastSuccessfulBuild/artifact/repository 

This install might need you to posses the following papyrus nightly build address in your available update sites as the developper tools depends on some plugins contained in it:

https://hudson.eclipse.org/papyrus/job/Papyrus-XYZ/lastSuccessfulBuild/artifact/repository/  

Install the tpd updater tool from this Github project from this update site:

https://dl.bintray.com/mbarbero/fr.obeo.releng.targetplatform/latest (4.1.0 and before)
http://download.eclipse.org/cbi/tpd/** (4.2.0 and after)

Papyrus (a clean clone is also useful to have for the builds as it will be much less susceptible to be corrupted by your daily work) up to date:

git://git.eclipse.org/gitroot/papyrus/org.eclipse.papyrus.git 

Simrel on which you will later post your updated aggregator file:

git://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git 

Another should have, not mandatory but useful, is the b3 aggregator editor to get a clearer view of the aggregator files in the simrel repository:

https://wiki.eclipse.org/Eclipse_b3/aggregator/manual#Installation


Update Papyrus Dependencies and References

You need to prepare the content for the next release by checking that everything depends on the latest releases of the train and that the versions are all up to date.


Publish The artifacts

When the produced artifacts are successfully produced by the Jenkins job and that you tested their installation and functionalities you will be able to publish them.


Checking the reports

At the end of each milestone you will need to check the installation from the staging update site and check the reports generated by the simrel aggregation job.

The simrel reports are available at :

  • https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/**BuildNumber**/artifact/target/repository/final/buildInfo/reporeports/index.html

And the simrel/staging update site at :

Preparing the GA release

When the final artifacts have been contributed and each milestones have been tagged in the repository, it is time to prepare the for the GA release.


D-day of the GA release

Keep in mind that depending on the date of your release review, you might have an official release day after the GA of the built Eclipse Package.

When the day comes however (meaning that the release is reviewed and the Eclipse has officialy declared the GA on the cross-project mailing list), you will have to:

  1. Run the GA publishing script,
  2. Amend the composites in the release folder to point to the new release and remove the dummy index.html file,
  3. Merge the prepared patches for the Website and your new development branch,
  4. Update the simrel file.

Finally, do not forget to remind the Papyrus Lead, again annoy as needed, to communicate about the release:

  1. mail in the mailing list dev,
  2. post on the forum.


This will end the release process. Good job! :)

Maintenance

After a while you will need to move some milestones and releases to the archives, meaning moving them from downloads.eclipse.org to archive.eclipse.org that is not mirrored. It is a good practice as it will save time, space and resources server-wise. The corresponding paths on the server are:

/home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/downloads/drops/
/home/data/httpd/archive.eclipse.org/modeling/mdt/papyrus/downloads/drops/

This can be done manually, until a better solution has been implemented, but be aware of the following guidelines:

  • d.e.o - downloads/drops: keep the last 2 or 3 releases depending on the span you want to cover and that the removed content has been copied in archive of course
  • d.e.o - updates/releases: everything here should be kept. Very old releases could be moved to the archive server depending on usage.
  • d.e.o - updates/milestones: this can be handled more loosely, but a good rule of thumb is to keep the last 2 or 3 milestones of what you want to keep in order to

allow eclipse to 'revert to previous installation' if needed.

  • a.e.o - downloads/drops: this needs to contain every releases published. There are no constraint on how recent or old they need to be so if you are not sure you will remember you can copy the release as soon as its out ;). You can also put milestones in here but that is not required.

Back to the top