SNAPSHOTS, Nightly, Milestones… oh my!

SNAPSHOTS, Nightly, Milestones… oh my!

There have been a discussion about build naming conventions lately.  SNAPSHOTS, nightly, milestone, GA, maintenance, integration, stable, etc…

In both Nick’s and Mickael’s posts, I noticed a theme: all builds are the same. Of course when they are built, or the process by which the built artifacts are vetted may change, but the build process is the same for all build types: namely, take what’s in HEAD/Master/Trunk/Tip/Top/Main Branch, tag it and build it.

This isn’t the case for the Eclipse project. The Nightly builds are actually done differently from the integration, milestone, stable, and maintenance builds.

The build processes that Nick and Michael mentioned, assume that once something is in Master/Head, it’s ready to be released and the only other variable is release date.  The Eclipse process doesn’t assume this.  In fact, I can release a wad of changes the night before Juno ships and likely none of them will be in build.  This is because Eclipse requires explicit tagging of what you want built.

Here is how it works:

  1. Development teams continually release stuff to master.  Each night master is built to ensure that nobody has introduced compile errors (or broke unit tests). This is not bleeding edge! This is not intended for anyone.  This is not similar to maven SNAPSHOTS.
  2. When teams are happy with their work, they tag the bundle.
  3. Integration builds happen weekly, and only what’s tagged will be built. Integration builds are similar to SNAPSHOTS, and can be consumed (if you want the most bleeding edge stuff).
  4. This has recently changed, so instead of tagging each week, we merge (from master into ‚integration‘). This means, what’s in master won’t necessarily be in a build each week.

I’m pretty sure I can hear the GitClub screaming feature branch, feature branch, feature branch. Why don’t you just use feature branches?

Please keep in mind:

  1. Eclipse is over 10 years old, and predates Git.  Would you really do feature branches with CVS? (maybe)
  2. The Eclipse build takes a while to complete:
  • Let’s assume it takes 6 hours to build and run the tests (1/4 of a day).
  • Let’s assume there are 10 teams (SWT, Debug, Workbench, PDE, JDT, UA, etc…)
  • Let’s assume each team has 2 features on the go at all times: 20 feature branches
  • Right now (for better or worse) a full Eclipse build, plus platform tests must run on the Eclipse build infrastructure
  • So, if we had 20 feature branches that we had to build in sequence, it would take 5 days to build todays nightly
  • Tomorrow’s nightly would start once that’s done!

Yes I realize some of those assumptions might be rather simplifying — maybe we could run the builds in parallel and off-load the costs to the hardware, but having a central build of 20 feature branches is still not feasible.  Also, some teams would likely want to combined builds (now build the SWT + Workbench feature branch together).

I know some people will head down the path of build restructuring (completely refactor the Eclipse build so developers can run them locally, thus removing the necessity for a centralized builds). We’ve heard this before many times.  Instead of suggesting this, sponsoring the effort (with money + people power) would be more helpful.  Also remember that Eclipse has successfully shipped on-time for the pat 10 years.  So, if you really want the team to change their process to the development flavour of the week, be prepared to show some evidence that process XYZ is better.

This was not meant to start a development war, but rather explain a bit about how the Eclipse build process works.  For better or worse, it’s what we have.

BTW, what do others do? Does everyone use feature branches and assume what’s in Master is ready? What did you do before Git (did you use branches for development in CVS/SVN)?