SimRel/Simultaneous Release FAQ
- 1 Introduction
- 2 How do we join the simultaneous release train
- 3 That's too easy, how do we join the simultaneous release train, really
- 4 What are the most important URLs
- 5 Where can the common repository be tested, before it is rolled out for a milestone or release?
- 6 Once I update my .b3aggrcon file, how can I start a build?
- 7 But what if I really want to kick off the build myself?
- 8 A build failed message says it can not find xyz.feature.group, but I have nothing with "feature.group" in the name?
- 9 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?
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.
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
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.
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).
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):
Then click the "Schedule a Build" buttton:
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.