Oxygen/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 site.
2. Provide data for Infocenter docs, for help.eclipse.org (see bug 495171) Infocenter participation has changed from opt-in to opt-out, see bug 499411.
3. Put your final bits in their final resting places, with their final names, early -- during quiet week -- but do not advertise them or 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 28, check cross-project list approximately 10 AM (Eastern) to make sure there is no "Wait! Stop ship!" 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, Fred, and Eclipse Foundation staff) on who does what, when, to make the Simultaneous Release available.

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

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", and b) it allows time for 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 -- produced at 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.

Check Info Center

Make sure your content in the info center is correct.

Beginning with Neon.2 the primary contents of the info center is automatically determined based on the presence of "org.eclipse.help.toc" extension in the plugin.xml file of a bundle. If anyone needs to "opt out" of the info center, please open a separate bug naming the exact bundle or bundles to omit. [As of now, assume "Cross-project" component is the best place to open those bugs.]

Similarly, if your project is not literally in the the Simultaneous Release repository then open a separate bug naming the exact bundles to include (and where to get them from). To be explicit, anyone that has a formal release can be in the Eclipse Foundation's overall "Info Center" -- only those in the Simultaneous Release repository are added automatically.

Provide input for overall New and Noteworthy

In addition to finishing or polishing your own project's "New and Noteworthy" please provide input for the overall Release New and Noteworthy document. This is prepared by the EMO based on input provided by the projects. For more "How To" information, see Overall Release New and Noteworthy.

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 helpful Eclipse webmasters at webmaster@eclipse.org and work out a plan to accommodate your special situation.

Projects should ensure their repository sites and *.aggrcon 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 creation 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. There is a wiki page that explains "how to", if you do not already know.

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
• [Christopher] 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
• Christopher publishes 'Oxygen 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

• Denis to update alias for default http://help.eclipse.org to go to http://help.eclipse.org/oxygen
• Denis (and/or Fred) will do a mirror-site sanity check if needed.

09:30 EDT

• Christopher and Markus start with the preparation for the downloads page without making it visible.

1. Downloads page:
   1. remove friends early access banner on downloads page
   2. remove Developer Builds tab
   3. replace Eclipse Neon (4.6) Packages with Eclipse Oxygen (4.7)
2. Re-enable Packaging Site Cron Job.
3. Oxygen http://eclipse.org/oxygen/ becomes Eclipse.org homepage.

10:00 EDT

• Fred 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.

• Fred and Markus to "flip switch" on SimRel p2 repository and the "trusted" EPP repository, making final release content visible to p2. We have a Hudson job which acts as a "one time" cron job to "flip the switch" of both repositories. This means if we do NOT want it turned on at the last minute, someone must 'disable' that Hudson job. It is at

https://hudson.eclipse.org/simrel/view/Releng%20jobs/job/simrel.releng.makeVisible/

• Christopher

1. Oxygen landing page:
   1. Remove "Learn more about Eclipse Oxygen".
   2. Replace "June 28, 2017" with "Now Available"
   3. Add the release day below the logo in a smaller font for historical purposes.
   4. Update Downloads link with http://www.eclipse.org/downloads/index.php
2. Downloads page will be published
3. Oxygen http://eclipse.org/oxygen/ becomes Eclipse.org homepage.

11:00 EDT

• Kat

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

Update meta-data

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

• Fred 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.

• Projects typically tag their released code with some human-readable tag so it easy to determine what code was in the release.

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 webmasters ... but otherwise, begin celebrations!