[linuxtools-dev] Builds for Helios maintenance and Indigo

[Andrew Overholt <overholt@xxxxxxxxxx>]

Hi,

I've restarted our Hudson jobs.  We have two active ones:

  https://build.eclipse.org/hudson/job/cbi-linuxtools-Helios/
  (builds towards Helios service releases)

  https://build.eclipse.org/hudson/job/cbi-linuxtools-Indigo/
  (builds towards our Indigo contribution)

They both run every 6 hours if SVN has changed.  For Helios, this means
that <component>/branches/0.6.0 must have changed to trigger a build.
For builds towards Indigo, it's trunk that must have changed.

Corresponding update sites are:

  http://download.eclipse.org/technology/linuxtools/updates-nightly-helios/
  (builds towards Helios service releases)

  http://download.eclipse.org/technology/linuxtools/updates-nightly
  (builds towards our Indigo contribution)

The question now is what we do for Helios service releases.  We have a
few options:

  1. Release 0.6.1 as a part of Helios SR1 (late September)
  2. Release 0.6.1 into our own update site sooner than September (we
     don't have to do a release review if it's bug-fix-only so we can do
     this soon)

If we choose 2. we have more options:

  3. Release 0.6.1 (or maybe even 0.6.2 by then) into Helios SR1
  4. Release 0.7.0 into Helios SR1

Option 4. is interesting.  It's definitely not the "norm" to do minor
(remember major.minor.micro) releases mid-"stream" but it's happened
before to increase adoption.  I think we definitely have a case for
doing this and EGit is planning on doing something similar for SR1.
This kind of release may add new features, change APIs, etc.  

What do people want to do?  I'm all for maintaining fewer branches.  If
we don't start using Indigo features and have enough new stuff to
justify a 0.6.x -> 0.7.x jump, I'm fine with releasing 0.7.0 from trunk
into Helios SR1.

Opinions very much appreciated.

Andrew