We're still debating what to do with the SR-2. The proposal was an early conservative one that was aimed to appease the community that doesn't want to live on the bleeding edge. Egit, you pretty much have to live on the bleeding edge since it's still pushing some basic features that everyone needs.
But I could see us forgoing SR-2 altogether at some point and release the Dec CDT release at SR-2 time. I just think releasing random lineups every 4 months as somewhat happens now with those projects doesn't give you that focus on producing a known line-up that just works (and as we all know, we have had issues with Egit just landing randomly in a release cycle). SR testing is much lighter than release testing from my experience. From: Ian Bull <irb...@eclipsesource.com<mailto:irb...@eclipsesource.com>> Reply-To: Cross project issues <cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>> Date: Tuesday, 2 July, 2013 5:03 PM To: Cross project issues <cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>> Subject: Re: [cross-project-issues-dev] 6 month release cycle 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<mailto: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<mailto:irb...@eclipsesource.com>> Reply-To: Cross project issues <cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>> Date: Tuesday, 2 July, 2013 4:08 PM To: Cross project issues <cross-project-issues-dev@eclipse.org<mailto: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<mailto: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<mailto:cross-project-issues-dev@eclipse.org> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org<mailto: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<mailto: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
