Jump to: navigation, search

Difference between revisions of "SimRel/Simultaneous Release FAQ"

(How is a final build made "invisible" until release?)
(How is a final build made "invisible" until release?)
Line 106: Line 106:
  
 
There is a few ways to accomplish this, depending on if you have composite or simple repositories, but they all involve promoting the "main" parts of the repository (the artifacts, usually "plugins" and "features" directory) to their final location so those meaty parts can be replicating to mirrors, but do not put the metadata (usually content.jar and artifacts.jar) to their final location until "release day". p2 doesn't "see" the artifacts, until it can read the metadata.  
 
There is a few ways to accomplish this, depending on if you have composite or simple repositories, but they all involve promoting the "main" parts of the repository (the artifacts, usually "plugins" and "features" directory) to their final location so those meaty parts can be replicating to mirrors, but do not put the metadata (usually content.jar and artifacts.jar) to their final location until "release day". p2 doesn't "see" the artifacts, until it can read the metadata.  
 +
 +
= Can a new project or feature join a Simultaneous Service Release (SR1 or SR2)? =
 +
 +
Yes, but still subject to all the other rules of the Eclipse Development Process and the Simultaneous Release Requirements. For example, if a "Release Review" is required by the EDP, it is still required, before being in an SR. A release review is normally not required for a maintenance release, if the maintenance is "bug fixes" only, but if a new feature is added (including an increase in minor version number) then according to the [http://www.eclipse.org/projects/dev_process/development_process_2010.php#6_4_Releases Eclipse Development Process] a release review is required. All that is independent of the "Simultaneous Service Release" and Planning Council ... just normal Eclipse business. Similarly, something "new" must still meet all the other Simultaneous Release requirements, such as signed jars, 4 part versioning, etc. In particular, the addition must "do no harm". In practice this means it is relatively easy to change "leaf components", but more care and effort is required to change a "low level" feature.
 +
  
  
  
 
[[Category:Indigo| ]] [[Category:Coordinated]]
 
[[Category:Indigo| ]] [[Category:Coordinated]]

Revision as of 12:39, 3 August 2011

Introduction

This page is to document answers to frequently asked questions about the yearly Simultaneous Release process or build.

How do we join the simultaneous release train

  • You need to mark the simultaneousrelease flag in the Foundation's Portal metadata for your project ... by M4, at the latest. After you mark that flag, the project lead should see some extra "tracking" metadata at the Foundation Portal.

SimrelFlagEdit.png SimrelTracker.png

That's too easy, how do we join the simultaneous release train, really

  • The flag is the only formal step in declaring your intent. Of course, your PMC should be well aware of your plans, as always. Some people like to post a note to cross-project list, which is not necessary, but does not hurt anything either, if you just want to keep everyone informed. Then, of course, the real work begins. There is a whole list of things you have to do, some required, some recommended, and, you need to get yourself into the common repository aggregation build, by M4, at the latest for new projects (existing projects continuing from previous years should already be in, as part of the intent it to be "simultaneous" every milestone, not just at the end. You will want to read through these documents, and others at the main wiki category (e.g. for Indigo) as there is a lot of work involved ... more than just "releasing at the same time of year". And, if it is after M4, there is an exception processes, but you should talk to your PMC and Planning Council representative to see if you have a reasonable case for your Planning Council representative to take to the whole council.

What are the most important URLs

  • Indigo, the wiki category page for the current simultaneous release stream. (Previous was Helios.)

Where can the common repository be tested, before it is rolled out for a milestone or release?

The best place is the "staging area", by adding this URL to your "available software sites" list.

http://download.eclipse.org/releases/staging

Note: to get the best test, disable all other repositories in your list, or you might end up pulling something from some other repository, not staging. Be aware that moving a specific build to "staging" may happen only every few days (if you need something promoted more urgently, just ask on cross-project list).

What is the staging repository?

Conceptually, it is simply a place to hold a repository temporarily ... until the repository is promoted to a released location.

What is staging, for the current, most forward looking, yet-to-be-released stream?

http://download.eclipse.org/releases/staging/

Not every build-repository makes it to this staging repository, but they do fairly frequently. Before the actual yearly release, a common milestone aggregation build is moved from 'staging' to the 'releases' area. For example, once, for each final milestone, staging is moved to

http://download.eclipse.org/releases/indigo/

What is staging, for the maintenance stream?

http://download.eclipse.org/releases/maintenance/

Not every build-repository makes it to this staging repository, but they do fairly frequently. There are no milestones for maintenance streams, so this is as far as a maintenance repository gets, until it is time for SR1 or SR2 to be declared at which time 'maintenance' is promoted to be part of the composite for the release, such as

http://download.eclipse.org/releases/helios/

What's the best way to test with the staging repository?

There are a couple of good tests to do, before a staging repository is released:

Test staging all by itself

Just add the staging repository to the available software sites, using preferences, and ... very important ... make sure all other sites are disabled. This then gives you the best view that everything in that one repository is correct, and all dependencies can indeed be found, and things show up in categories as expected.

After confirming the categories are as expected, usually the next test is just to install things, fresh, but often it is a good idea to test various update sceneries, to make sure things work as expected (for example, if you already have M6 installed, then once M7 is ready, test to be sure it updates to M7 as expected.

Test staging as a pseudo composite

After confirming staging repository is correct, its often useful to then also (re)enable the released repository. Then, on install dialog, you can select "all available sites" and this effectively simulates what the eventual, final composite repository will look like to end users. There are cases, especially during initial development, where invalid features will show up. For example, if a feature was removed, renamed, its version reduced, or its category changed from one milestone to the next, it might still show up in the composite, and that might interfere with correct installation (see bug 314165), if not merely be confusing to end users. If there is a serious problem due to the composite, please open a bug in cross-project component and we'll decide if the composite should be changed or reduced to allow for correct installation.

Why do we use composites anyway, if there are potential problems with them?

Two reasons. While the eventual, initial released repository, in June, will definitely consist of just one set of released, consistent features, later in September, and then February, we use composites to add maintenance, so testing composites early is a good idea to make sure there are no bugs in p2, etc., that need to be fixed.

Secondly, someone may be using a previous milestone as a runtime target, and once we remove it, it will invalidate that target, so we do not want to force everyone to "move up" all at the the same time. Some developers may need a few weeks to transition to the latest code. To save space, we do not try and save all previous milestones, though. Our goal is to maintain about 3 milestones in the composite. For example, if we had M4, M5, and M6 in the composite, once M7 came out, we'd only have M5, M6, and M7. But the number can not be guaranteed. If there are serious problem with providing the composite we will reduce it to just two, or even to just one, to make sure the repository is usable for testing and continued development.

Once I update my .b3aggrcon file, how can I start a build?

You don't need to. The build will start automatically, once you check in a .build file. The .build files are checked every 15 minutes to see if any have changed, and if so an aggregation build will start. It takes approximately 2 hours to run.

But what if I really want to kick off the build myself?

If you can't wait 15 minutes, you can start the build your self. Anyone that has authorization to check in a .build file, should have authority to manually start a build. Plus, there are some cases where someone may need to kick off a build manually. For example, if a build fails due to network issues. Another common case is that a build may fail, even though the .build file is correct, the repository it points to might have had an error. Once the repository is corrected, there's no automatic mechanism to detect that change, so after the repository is corrected, a new build has to be manually started (that, or the .build file "touched" and then checked in again). To manually start a build, just click the "Schedule a Build" button at the build status control page.

You need to be sure to login (with your committer ID):

SimRel login.png


Then click the "Schedule a Build" buttton:


SimRel build.png

A build failed message says it can not find xyz.feature.group, but I have nothing with "feature.group" in the name?

The suffix ".feature.group" is added to feature names, to refer to the whole feature ... the feature files themselves, but also all its included bundles and features ... to help distinguish it from the literal feature files. So "xyz.feature.group" just means the "xyz feature", conceptually. See Eclipse Help for detailed information about metadata.

A build failed message says it can not find version 1.2.3.v9 but I can see 1.2.3.v9 on the file system?

The key file, the one that "drives" P2, is the content.jar/xml file. Be sure to check the version numbers there. If, inside it, the installable unit (often a feature) says version="1.2.3.v8", then P2 will look no further and conclude that the 'v9' feature it is looking for is not there. This is usually a sign your meta data needs to be re-generated to match the contents on the file system.

How is a final build made "invisible" until release?

Web download pages?

You can put the zips in their download directory, so those large items can replicate to mirrors, but don't use any HTML that would cause them to be displayed as links to an end user. True, if someone knew the exact URL they could still get it, but the idea is that the URL is not widely announced or visible, so even if a few download it, it is not hit by thousands of downloads. Then, on release day, you'd update the HTML pages to make the downloads visible to browsers and click-able by users.

Tip : you can hide some particular builds from download pages using the hidden.txt file in downloads directory ( see for example emft : http://dev.eclipse.org/viewcvs/viewvc.cgi/www/modeling/emft/downloads/hidden.txt?root=Eclipse_Website&view=log )

P2 repositories?

There is a few ways to accomplish this, depending on if you have composite or simple repositories, but they all involve promoting the "main" parts of the repository (the artifacts, usually "plugins" and "features" directory) to their final location so those meaty parts can be replicating to mirrors, but do not put the metadata (usually content.jar and artifacts.jar) to their final location until "release day". p2 doesn't "see" the artifacts, until it can read the metadata.

Can a new project or feature join a Simultaneous Service Release (SR1 or SR2)?

Yes, but still subject to all the other rules of the Eclipse Development Process and the Simultaneous Release Requirements. For example, if a "Release Review" is required by the EDP, it is still required, before being in an SR. A release review is normally not required for a maintenance release, if the maintenance is "bug fixes" only, but if a new feature is added (including an increase in minor version number) then according to the Eclipse Development Process a release review is required. All that is independent of the "Simultaneous Service Release" and Planning Council ... just normal Eclipse business. Similarly, something "new" must still meet all the other Simultaneous Release requirements, such as signed jars, 4 part versioning, etc. In particular, the addition must "do no harm". In practice this means it is relatively easy to change "leaf components", but more care and effort is required to change a "low level" feature.