Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Luna/Final Daze

Final Days: Introduction and Summary

The final days leading up to our annual Simultaneous Release is similar to previous years, but especially those new to the process may want to read closely to help make sure everything goes smoothly.

This schedule and procedure should ensure the mirror system gets fully populated before demand for downloads gets in full swing -- meaning much fewer delays, 404's, and failed downloads.

For most committers (or, specifically, release engineers, or project leads) the following are the main steps.

  1. Clean up old builds on downloads and move previous releases to archives.
  2. Provide data for Infocenter docs, for help.eclipse.org bug 436372.
  3. Put your final bits in their final resting places, with their final names, early -- during quiet week -- but don't advertise them, and don't make "visible" to the world. Be sure to change, correct or add metadata -- such as download.php mirror URLs -- so they are correct for final location and names.
  4. On official release day, Wednesday, June 25, check cross-project list approximately 9 AM Eastern to make sure there is no "Wait!" message. Once you see a "Go" message, you're free to advertise your release and make visible to the world. (And, while your thinking of it, just as well update Foundation's metadata to change "planned" to "completed", etc.
  5. Keep an eye open for a few hours to make sure no reports of "bad things happening", but otherwise Blog, Tweet, Celebrate!

If you've been through this before, those reminders may be all you need to read. If this is your first time, or just need to refresh your memory, you may enjoy reading this whole document, which has some reasons and details behind the steps and links to "how to" documents. Some of the end of this document is just reminders for the "core team" (i.e. Markus, David, and Eclipse Foundation staff) on who does what, when, to make the Simultaneous Release available.

From "Now" to official release (which is Wednesday, 6/25)

Clean up "old" builds and archive earlier releases

Delete "old" builds and milestones and archive previous releases. This is important to reduce the disk space used, not just on eclipse.org servers, but more important, the space used on the mirror servers. Not only is this a "nice" thing to do, it is essential for the yearly release, as it can help the mirror servers avoid filling up trying to get the final release, which results in them not actually mirroring the release. And, of course, if they have problems, we all have problems! Every project should have space at, if not already using, archive.eclipse.org, and if you are not sure how to archive files, please ask (it is easy). Having the files on 'archives' allows seldom downloaded files to be retained forever without being mirrored (and, if not obvious, no need to mirror, since seldom downloaded).

We ask that this clean up be finished approximately one week before the official release so a) all mirrors can be sure to easily get "synced up" with the new minimal amounts, and b) it allows time for some inspections and audits. Projects that appear to be non-compliant may be asked to explain their use of Eclipse.org resources.

Final Simultaneous Release repository and EPP packages -- end of RC4

The Milestones and Release Candidate dates are defined in the Simultaneous Release Plan.

RC4 is considered final, to be followed by a quiet week reserved for final testing and final preparations for the release.

The "final build" means that all content must be frozen; features, plugins, versions, etc. Some content might still have an "RC" in zip file name, or be on a "temporary" repo site (such as, ...<project>/milestones) and later (such as during quiet week) renamed and moved to a "permanent" site (e.g. ...<project>/repository) but during that rename and move, there should be no change to plugins, features, versions, repository metadata (artifacts.xml/jar files and content.xml/jar files). When that move or rename happens, there will often be changes required for download pages and p2 metadata. For example, when the p2 artifacts metadata (artifacts.xml/jar) is moved to its final location, be sure its p2.mirrorsURL property is updated to reflect the new location of the artifacts (see "how to enable mirrors"). Some projects also may also have a version-specific p2.statsURI property that needs to be updated. (See p2 download stats).

The (not entirely) Quiet Week

Finish final testing

Projects will have normally finished all testing by now, but, still, quiet week is a good time for committers and especially adopters to do more testing. At this point, while it is too late to fix a bug and rebuild, it is always best to know about a bad bug or regression before users run into it. In some cases, a project may want to prepare a "patch" or workaround instructions before the release. Normally, discovering a "bad bug" during quiet week is not justification to rebuild the repository and EPP packages. Normally, the only reason for any complete rebuilds during quiet week would be if there was a bug that affects installation or update itself, or there were some IP (Intellectual Property) or release irregularities requiring removal of some project's files or bundles.

Finish Info Center

Provide documentation bundles locations (for copying) in bug 436372.

Prepare releases (renames, etc.) off-line

There is no need to wait until "the day before release" for projects to put their artifacts in their final location, but they must remain "invisible" until the official release day. It is actually important and encouraged for most projects to get artifacts into their final locations "early", during quiet week, instead of the "day before release" so that mirrors have a number of days to get caught up. If everyone promoted on the one day before release, it means the mirrors are very busy pulling content the day before, and have trouble getting caught up and to a steady state before the actual release. (From casual observation, it takes roughly 4 to 7 days for all mirrors to get in sync, though a few are updated within half a day, and a fair number are within one day).

During quiet week, prepare your final releases zipped files, repository sites, etc., but only put zipped-up builds, update jars, etc., in their final (mirrored) release areas of eclipse.org if you leave them "invisible". If you do not know how to leave them invisible, please see the "how to make invisible" FAQ or ask for clarification on cross-project list. If you have a special circumstance that does not fit in the normal procedures and schedule, please send a note to cross-project list or discuss with our Eclipse webmasters (Denis or Matt) at webmaster@eclipse.org and work out a plan to accommodate your special situation.

Projects should ensure their repository sites and *.b3aggrcon files stay coordinated, so the common site can be re-created on a moment's notice, if required.

If you do need some official, final release URL of a specific pre-req project (such as to update your final release pages, please work with the project to find out what it is ... since it will not be "visible" through the normal channels.

Note: we do not have formal "sign off" pages, so it is critical that if anyone is the least bit late (or even close to being late) to meeting a deadline, please keep everyone informed via cross-project mailing list.

Tip: When you copy/push your final content, do not use -t in your rsync commands, but let the file time take on the current time that the copy was done ... the reason is that the mirroring system uses timestamps to infer what's been mirrored and what has not, and a file that appears "old" may end up being assumed mirrored already, when in fact has not been mirrored yet ... which will result in users getting 404s from mirror site URLs.

Common repository site and EPP preparation

It is assumed "staging" content is complete and final EPP packages prepared by the end of RC4. There may need to be some adjustments needed during quiet week to some of the composite repository files so they point to the final location of EPP repository.

Remember, EPP RC4 is not available like usual, nor is the RC4 "staging" repo promoted to /releases/<releaseName> like usual -- at the end of RC4 -- or, else, we would be "releasing" early.

The common repository and the EPP packages, though, will be moved to their final locations, but left "invisible", so they can have plenty of time to propagate to mirrors.

Remember to check that artifact repositories have correct "p2.mirrorsURL" property and or composite values, if needed.

Monday before Wednesday's Release

By end-of-day (5 PM Eastern) all projects should be "done", having prepared content, at final locations, even though still "invisible" to normal web browsing and p2 installers.

Monday is the last opportunity for anyone to declare "emergency, stop ship" (and it had really better be an emergency)!

Tuesday before Wednesday's Release

By 10:00am EDT

[Markus] Check availability of the package archives, file names, checksum files, XML configurations for the web site
[Chris] Disable the Cron job from updating the Packaging Site until 9AM Wednesday
  • Denis sends out mail to the members participating at the Member Downloads Program
  • Chris publishes 'Luna is here for Friends only' page for the main downloads page; links for Friends mirrors and Bit Torrents only
  • Denis Emails Friends of Eclipse with details on how to get the downloads from the friends mirror.
  • wait overnight, make sure mirror are well populated, etc.
  • projects should prepare final web pages, announcements, press releases, etc.

Wednesday (Release day)

08:30 EDT

09:00 EDT

  • David to announce on cross-project list that the release is available, and Projects can now make their download pages and repo sites visible, and announce to their user communities.
  • David to "flip switch" on common repository, making final release content visible to p2.
  • Markus to "flip switch" on trusted EPP repository /technology/epp/packages/luna - should be synchronized with the common p2 repository switch
  • Christopher
  1. Luna landing page:
    1. Remove "Learn more about Eclipse Luna".
    2. Replace "Coming June 25, 2013" with "Now Available"
    3. Add the release day below the logo in a smaller front for historical purposes.
    4. Update Downloads link with http://www.eclipse.org/downloads/index.php
  2. Downloads page:
    1. remove friends early access banner on downloads page
    2. remove Developer Builds tab
    3. replace Eclipse Kepler (4.3) Packages with Eclipse Luna (4.4)
  3. Re-enable Packaging Site Cron Job.
  4. Luna http://eclipse.org/luna/ becomes Eclipse.org homepage.

10:00 EDT

  • Roxanne
  1. Announcement of Luna on social media.
  2. Update Eclipse News with a Press release about Luna (English, French and German)

Update meta-data

These do not necessarily have to be done on the release day, but then, or shortly after.

  • David updates Simultaneous_Release wiki page (such as, removed "planed", change to final URLs, etc.).
  • Project Leads should update their Project meta-data at Foundation Portal, when needed, to update "complete" status, final download URLs, etc.

12:00 EDT

  • Earth Shattering Kaboom - Wait a bit to see if any obvious issues. Make sure your pages are visible, can perform downloads and updates ... report issues to Denis :) ... but otherwise, begin celebrations!


14:00 EDT - Ottawa Committer celebrations

Back to the top