>Tag/Build, Build/Tag..How about Both

>Nick blogged about some ways to feed your builds. Many in eclipse, like the Tag and then Build approach.

….when a number of changes are ready to be released, a tool such as the org.eclipse.releng.tools plugin can be used to, in a single operation, both tag the sources and release those tags into the map file.

Nick goes on to point out the advantageous to this:

This permits a granular approach to plugin versioning wherein only the plugins which have actually changed are renumbered, and thus incremental updates between releases is possible, and if only a single plugin changes from week to week, only that plugin will be upgraded.

I agree with all of this, however, where I disagree is in the following statement:

The only issue with this approach is that it introduces extra overhead, unless the tag&release process can be automated and run on a (weekly?) schedule

I don’t think that the extra overhead is the only problem with this method.

1. I’ve seen many times where Integration and even Milestone builds are promoted for general use even though they have failing tests. How can the user community be confident if your tests are red on a build you promote for them to use?
2. How many times has code been tagged and released that did not go through any type of testing? How many times has this caused a build failure.
3. How often are your Tagged builds producing good builds?
4. How easy is it for me to pull out the code from a TAG only to get all the code that was used to produce that build. With a MAP file there are many, many different tags that are used to produce a build. Unless the MAP file itself is tagged with a unique TAG name that identifies it’s build, you have to wade through revision histories and hope to get the correct tag.
5. MAP files are very eclipse project specific. It is a barrier to allowing people to easily get code out and reproduce a particular build. Working with eclipse projects and getting the code to build is not as easy as it should be. Note not all eclipse projects require OSGI or even eclipse to run. Some examples, Mylyn Wiki Text, EMF Runtime, PsychoPath XPath 2.0 processor, Jetty, etc.
6. You have multiple map files to deal with. What if somebody didn’t release the right code into a map file, or forgot a map file? A long running build can require several hours to reproduce. 6 plus hours in the eclipse platform case.
7. MAP files do not easily allow for Incremental builds to occur. It requires a clean build to be done. One of the longest parts of a build can be just checking out the code and getting the environment setup.

Now I do agree that Integration and Milestones builds should be tagged. I disagree that MAP files are the way to do this. Another approach is to build your code and then TAG all of it with the same TAG.

1. This allows people to get the exact code at that time out if necessary. If they want to rebuild or work with code from Milestone 3.6M6, they check out the code tagged 3.6M6.
2. An hourly or continuous integration build that is tagged, can be promoted, or if using Hudson, you can have Hudson tag a specific build. These builds then can be used in further testing and as artifacts for other builds.
3. It allows any build to potentially be released to the community at any particular time. If a build is deemed worthy of a release, it is Tagged and promoted to the Integration site.
4. Build and Tag can potentially respond quicker to the community needs than Tag then Build. If a build needs to be promoted sooner, a clean build from head can be promoted with out having to figure out which TAG or map version it was created from.
5. There is less human error involved and fewer manual steps that need to be taken.

The Hybrid Approach that Nick mentions is a good compromise for some projects to take. Particularly if your entire project can be built in 20 minutes. If your project takes longer, you may need to start looking at breaking your long running build into shorter component based builds. You may still want to keep that longer running build for a Nightly build, and to use as Integration builds. You even have an option TAG these builds afterwords to allow Promotion to a stable build.

Doing CI builds makes sure that your code that is in HEAD is always clean. That your user community can always get a good clean snapshot of the code. Builds that are just based on maps with no CI aspect are just a factory for bugs to breed and builds to break more often. Breaks with CI builds are usually short lived, as the build notifies sooner rather than later the programmers involved.

The bottom line is that there are multiple ways to do your builds. What works great for one project may not necessarily be the way to do it for all projects. That has always been my main issue with PDE build and the Eclipse Projects Development Process. It tries to enforce a particular decision made years ago, on the entire community as a whole. Athena does a lot to allow some flexibilty while still leveraging PDE build when it needs too. However, One way does not fit all.