I agree with service releases. I know a few project that do service releases when they need, not tied to the train. It’s certainly more flexible for the projects to do what they need to do. But before we go that way, I want to make sure that when a user
selects Check for Updates, that it picks up these off train, i.e. off simrel repo, service releases. I’ve heard anecdotal evidence in the past that this didn’t work.
Will have to let the June/Nov cycle soak a bit. What I don’t want to see is where one of the releases is more important than the other. Part of my objective behind the 6 month cycle is to change the culture so people are thinking we release every 6 months
and that becomes our habit. If we were late enough in November or maybe into the first week of December, that might be OK. Or maybe we leave Neon in June and move to May in 2017. But then I’m not totally sold on May/Nov over Apr/Oct yet either.
Doug.
Doug, thank-you for starting this conversation.
Let's challenge a few assumptions first. What is the point of having Service Releases (SRs) for the entire train? Do we need them? I understand that individual projects may want to have service releases, but does the train as a whole, need them? Historically
we followed the schedule of the Eclipse project itself, and this is a good pattern for the platform, but do we need this for the entire train?
What if we had two releases each year, starting with 15.11 this fall (Nov 2015) and 16.06 next year (June 2016). The Eclipse project itself could keep it's same milestones and contribute it's SR1 to 15.11, but train itself would use milestones similar
to what you suggest. (I'm suggesting June 2016 because that way the Eclipse project could keep the exact same milestones it already has).
This actually is less work simultaneous release because there is now only one stream.
Thoughts?
Ian