Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Shorter release cycles (cont...)

Indeed a great discussion and again Thank You all for contributing and being open to the idea. I feel something great coming out of it. :)

First for Ian’s question, yes, one repo at a fixed URL. It’s a requirement I have of my customers to be able to update from release to release. Our schedule is somewhat random and driven by other forces so they don’t really know which Eclipse Platform release their getting unless they look hard at it. They’d be pretty confused if they could upgrade to some but not others.

I also wanted to add a bit of history that not many people know about other than long time CDT committers that were around at the time or heard my old grampa stories over CDT Summit beers…

Before CDT joined the train, our release strategy was a mess. And it was really the diversity of our project that caused it. We had two major players, I worked for one and I now work for the other (hint, hint). One of them had a product based on CDT and that product delivery schedule was driven by the platform it supported. The other was trying to release in sync with the Eclipse platform so it could feed into the product stack that that company was building on top.

The problem crept up with the two schedules didn’t match. What ended up happening was that CDT released every time one of these two stacks needed a release. Unfortunately, the committers remained focused  on their product release and ended up not helping the other out when it was time for them to release. In fact, on one famous occasion, the one who had a few months before their release added a new feature two weeks before the other was going to have their release. Luckily we had great leaders back then and the commit was reverted.

It was a complete mess and as we started to grow committers from different ISVs, we started to ask, do we release every time one of them needed a release. That would have been complete chaos. So when the idea of the train came along I used the opportunity to standardize our releases and there was really little fuss because everyone knew that was the right thing to do and the answer was handed to us on a silver platter.

So while the idea of 3 month cycles is a great advance forward, I do fear the unintended consequences. If projects aren’t releasing on every train release, then they have a decision to make on which releases to release on. And what drives that decision? The old train gave us an automatic choice that we didn’t have to think or fuss about. Sometimes that’s a good thing.


From: Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
Reply-To: Eclipse Planning Council <>
Date: Wednesday, May 6, 2015 at 1:36 PM
To: Eclipse Planning Council <>
Subject: [] Shorter release cycles (cont...)

Great discussion today!

I really like the direction we are headed, and the idea of a release once per season would make us much more agile.

One technical thing we need to consider is how we will structure the repository. Currently we create a new composite repository every each (for the June release) and add the SR1 and SR2 when they become available. In the next year, we wipe the slate clean and start again with a fresh repository.

If we are moving away from a Release + SR1 + SR2 and moving towards a rolling release, then I don't think we should clear the repository each year. This will make year-to-year updates impossible. 

One suggestion is to create a single composite repository, and store the latest N releases (N=4?). When N+1 is released we then drop the oldest release from list of children (of course we could maintain the update site forever at a permanent URL -- but that would be part of our retention strategy which we have not yet discussed).

Thoughts? And thanks again everyone!


R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 |

Back to the top