|Re: [cross-project-issues-dev] 6 month release cycle|
It goes back to the primary goal behind simrel. The original goal was to synchronize the releases and aggregation was secondary. With some projects wishing to release more frequently and some projects slowing down, perhaps the primary focus should be on aggregation rather than synchronizing everyone’s schedule.
Suppose for a minute that we ran the aggregation process monthly. All projects contribute the latest finished release they have, dependencies are reconciled, some cross-testing happens and it’s out. Every month, there is a repo with versions of all participating projects that are known to work together. Users are happy because they only need to check for updates from the aggregate repository that delivers new stuff to them frequently. Projects are happy because they can set schedules that make sense for their needs and if they miss one deadline, the next opportunity is not that far away.
The schedule you propose is interesting Doug. Two things stand out -- Your december release only has a one SR. (There is no 8.3.2). The second thing is that you plan on maintaining your June (Kepler) contribution in Feb (Kepler SR2). This is fine, but this is the opposite of what others have done. EGit (and Mylyn too, I think) have released new versions with the SRs. I'm not going judge what's better, but I don't like the fact that they are different.
For example, the February 2014 will potentially have the latest and greatest EGit and a maintenance release of CDT after a new release was just announced. Combine that with the milestone stream that will undoubtedly be moving forward and our users will be hit with a confusing set of available sites from which to find their software. Also, what version of the CDT will be available in the MarketPlace next February?
I'm not picking on anybody here. I think this demonstrates that we need to do something regarding multiple releases per year, and I'm doing my best do understand the different constraints we have.
On Tue, Jul 2, 2013 at 1:28 PM, Doug Schaefer <dschaefer@xxxxxxx> wrote:
Thanks Ian, to answer your questions:
We do expect both releases to be the same quality and vendors will build on both, especially those vendors who need and are likely contributing the new features.
We would build the mid-term release on the June platform. Although, we would love it if the platform released on the same cadence since a lot of what we need requires changes to both (project/build, debug/launch). Not to mention any serious contribution to cleaning up the Eclipse Platform UI to improve look and workflows that would benefit everyone, but that's a whole other set of issues.
Both releases require their own ramp down so I'm not sure the M's would line up with the train properly. But I haven't looked at that yet.
We do acknowledge that we need to spin the Eclipse C/C++ IDE package every six months as well to ensure our objective of getting users the new features faster is met. And the marketing along with that would certainly help get the word out that a new release is available.
One of the things we need to understand is what do we want from a release train?
1. Is it simply a release of the latest and greatest stuff Eclipse has?
2. Is it a set of plugins / components that are known to 'work together'?
3. Is it a co-ordinated marketing exercise?
4. Is it a snap-shot in time of what we have?
5. Is it something else?
There is nothing wrong with components doing their own release and coming together 1+2 times a year (release plus SRs). In this case the latest and greatest are in the SR0, SR1 & SR2. We could also approach this from a two-stream perspective. Latest and greatest is in the Milestones, and the SR0, SR1 and SR2s are the LTS versions. Both of these will work, but I don't think we should mix & match approaches.
I'm sure with 71 projects in the release train, we'll arrive at 71 different meanings for the train.
Doug, in the case of CDT, could you consider M4 & M7 your 'releases' (after a few rounds of RCs of course)? What version of the platform do you want for your mid-term release (i.e. will Dec 2013 build on Kepler or Luna)? Do you expect / need marketing support for both releases? Do you expect both releases to be of the same quality (will vendors build on both)?
Just a few more questions to hopefully help drive the discussion :-)
On Tue, Jul 2, 2013 at 12:49 PM, Igor Fedorenko <ifedorenko@xxxxxxxxxxxx> wrote:
I agree, one year is way too long. I am not even sure 6 months is often
Back to the top