Ian is an Eclipse committer and EclipseSource Distinguished Engineer with a passion for developer productivity.
He leads the J2V8 project and has served on several …
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:
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:
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)?
Ian is an Eclipse committer and EclipseSource Distinguished Engineer with a passion for developer productivity.
He leads the J2V8 project and has served on several …