Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Proposal to move to 6 month release cycle

Yes, I mean tthe simultaneous update site.  Some project do put their latest release on that site.  I wonder if we shouldn't put our December release, and leave the user choose which version of CDT to select?


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Tuesday, July 02, 2013 2:57 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Proposal to move to 6 month release cycle

The SR-2's we've had in the past have been pretty minor with only serious issues fixed. Everything else was problems found because people didn't start adopting CDT until SR-1 with it's improved quality and they didn't want to wait until the next SR-1 for a fix.

I think moving to 6 month releases will change that since the next SR-1 is shortly after the SR-2. We may not even need the SR-2 in the end. But there are vendors I know that are slow to adopt and change and we'll need it there for a while.

BTW, what do you mean by main update site? It won't go the the simultaneous release site, unless, of course the simultaneous release joins us with a 6 month cycle :).

We'll need to figure a easy way to get the new release to users (and I do hate the p2 UI and it's UX). That's probably why we need to update the C/C++ IDE package as well.

D


From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Marc Khouzam [marc.khouzam@xxxxxxxxxxxx]
Sent: Tuesday, July 02, 2013 2:32 PM
To: 'CDT General developers list.'
Subject: Re: [cdt-dev] Proposal to move to 6 month release cycle

I think this is great.
The only thing I don't really like is the asymmetry of having two SR releases for the June release, but only one for the December release.   One SR release could be enough since the December release will provide access to other bug fixes.  However, I don't see any better way, since we want to follow the train. 
 
In Doug's example, we have some kind of release every 3 months (which is nice and well divided) + one SR2 (which is usually quite small anyway).  I think that is a good plan.
 
Would we put the December release on the main update site?


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Tuesday, July 02, 2013 12:29 PM
To: CDT General developers list.
Subject: [cdt-dev] Proposal to move to 6 month release cycle

Hey gang,

We talked about this on our call this morning. There is a lot of interest, and actually always has been, in moving to more frequent release cycle. Yearly is great if you are a stable platform that doesn't need to change much, but our feeling is that the CDT still has a lot of work left to do.

And I actually think that yearly cycles reduces the appeal of contributing to Eclipse. Who wants to make a contribution and then wait a year to have a release they can use it with. Even the major Linux distros release bi-yearly. But let's focus now on the CDT and maybe we can lead by example and join other projects that are already doing this.

So here's what we came up with and we need to hear from you and tweak it so that it's captures all our needs (or as many as we can).
  • Release in June along with the Eclipse release train as before.
  • Release the SR-1 for that release in Sept as before.
  • Release a new feature release in December, not too late where it interferes with the holiday season.
  • Release the SR-2 for the June release with the rest of the train in Feb as before to satisfy the needs of people stuck on the older CDT release.
  • Release the SR-1 for the December release in March or April.
  • Release in June again, and repeat.
So, for example, this year we have:

June – 8.2.0
Sept – 8.2.1
Dec – 8.3.0
Feb – 8.2.2
Mar – 8.3.1
June – 8.4.0

Anyway, before we decide to do this, we need to hear from everyone in the community. Please let us know what you think or if you have any questions (and there should be lots of questions).

Thanks,
Doug

Back to the top