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 _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
