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. Cheers, Ian On Tue, Jul 2, 2013 at 1:28 PM, Doug Schaefer <dschae...@qnx.com> 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. > > > From: Ian Bull <irb...@eclipsesource.com> > Reply-To: Cross project issues <cross-project-issues-dev@eclipse.org> > Date: Tuesday, 2 July, 2013 4:08 PM > To: Cross project issues <cross-project-issues-dev@eclipse.org> > > Subject: Re: [cross-project-issues-dev] 6 month release cycle > > 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 :-) > > Cheers, > Ian > > > On Tue, Jul 2, 2013 at 12:49 PM, Igor Fedorenko > <ifedore...@sonatype.com>wrote: > >> I agree, one year is way too long. I am not even sure 6 months is often >> enough. We had three m2e releases between Juno and Kepler, and I >> consider m2e mature, (relatively) low-activity project. At the same >> time, I never use R builds myself, I always use M-builds as primary >> development environment for my $DAY_JOB. I don't suggest we do >> full-blown release every 6 weeks, but maybe there is a way to elevate >> perceived status of M builds such that users are more comfortable using >> them. >> >> -- >> Regards, >> Igor >> >> >> On 2013-07-02 11:30 PM, Doug Schaefer wrote: >> >>> Hey gang, >>> >>> We have a discussion going in the CDT community and we are currently >>> planning out how to achieve a 6 month release cycle. The feeling is that >>> we need to get new features out faster to our users. The year long wait >>> we currently have is making releases sluggish and I fear it's slowing >>> down growth in our community. A 6 month cycle should infuse us with a >>> little more energy, so goes the hope. >>> >>> I mentioned CDT's plans on twitter and a number of senior members of our >>> larger Eclipse community thought it might be a good idea for other >>> projects at Eclipse and maybe for the train itself. And I think so too. >>> >>> Instead of continuing that discussion on twitter, which is fun and >>> everything, I thought we should bring that to a greater audience and see >>> what other projects thought and whether it's something we should bring >>> to the Planning Council and the rest of the EMO. >>> >>> I know there are a number of projects already releasing off stream >>> during the year, but bringing things together more often might be a help >>> to many others. But I'd like to hear your thoughts on that. >>> >>> Doug. >>> >>> >>> ______________________________**_________________ >>> cross-project-issues-dev mailing list >>> cross-project-issues-dev@**eclipse.org<cross-project-issues-dev@eclipse.org> >>> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>> >>> ______________________________**_________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@**eclipse.org<cross-project-issues-dev@eclipse.org> >> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >> > > > > -- > R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 > http://eclipsesource.com | http://twitter.com/eclipsesource > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
