|Re: [eclipse.org-planning-council] 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 <eclipse.org-planning-council@xxxxxxxxxxx>
Date: Wednesday, May 6, 2015 at 1:36 PM
To: Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>
Subject: [eclipse.org-planning-council] Shorter release cycles (cont...)
Back to the top