| Re: [cdt-dev] Releases |
Actually, if it turns out there are not new features in master by the end of next week, and it would be easy to pull the launch bar out, we could still ship master as a maintenance release. Are there any new features there?
Thanks,Doug
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Doug Schaefer [dschaefer@xxxxxxx]Sent: Wednesday, August 13, 2014 6:00 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Releases
Thanks, Marc and sorry for disturbing your vacation. I appreciate your concerns. But comments below.
I would really like a minor release in December or we're missing the holiday season with these great new features. It would be really disappointing not to release the Launch Bar, and as a result my new Wascana work, until February. The LaunchBar will not be ready for feature freeze on Monday.
Two minor releases in two months is probably not what anyone had in mind. I think Derek was complaining already we were adding a new release.
Nothing prevents adopters from continuing to adopt the release train as a sole provider. They would just miss picking up the December release. In fact, that's how most adopters work anyway. They generally don't follow CDT releases when publishing their products. They just pick a build from whenever, test it, patch it, and then deliver it. No one is forcing you ("Ericsson") from adopting the December releases. You might want to wait until February anyway for all the early adopter bugs to be worked out.
If we do continue the 8.5 plan, we will need to prepare a release review ASAP. It needs to be filed by RC1 which is the end of next week. I will not have the time for that, so Marc you'll have some work if you are back next week. Mind you if there are no new features, it'll be easy. But then if there are no new features...
If we decide not to do a December release, then I propose we never try to release a minor release, and thus new features, in September. There's no way we can make any guarantees if we try it. That means you have two windows, Feb and June. I'm not sure that's good for the community. That's why 6 month cycles make more sense.
Thanks,Doug.
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Marc Khouzam [marc.khouzam@xxxxxxxxxxxx]
Sent: Wednesday, August 13, 2014 4:44 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Releases
Hi,
sorry for the delayed answer but I'm on vacation.
In summary I have the same concerns as Jeff and Derek and I would like to discuss this further before making a decision. Because, SR1 is very close, I suggest we don't change anything just yet and release 8.5 from master with SR1, I don't think there is a big drawback to that in itself. And we continue this discussion for 8.6 (which we can still decide to plan for December, although that is not my vote). I try to express my hesitations in detail below.
First, as Jeff pointed out, doing an 8.4.1 release off the 8.4 branch, instead of 8.5 from master implies more work this time because we were not expecting that. I was under the impression that the 8.4 branch was used by integrators that needed specific fixes for an older release; with that in mind, I didn't focus on duplicating bug fixes from the master branch to the 8.4 branch. So, like Jeff, and possibly others, I would need to go back and sift through the commits and cherry-pick the right ones. To do things right, I will need to test each bug fix. That's 14 bug fixes in the Debug component. I'm not very fond of retesting each one.
Second, some consumers of CDT repackage and release to their customers. This is our case. We include other projects in those releases, not just CDT, and those projects follow the Eclipse release train. This means that we probably cannot get away from having our internal releases match with SR1 and SR2. So a release in December will not provide much benefit for us, but will create more work (see next point).
The internal releases I mention have to be tested. We run thorough tests on each one (by 'we' I mean the Ericsson committers). Any issue found is fixed in open-source, so the community benefits directly from our efforts. As our packages include other projects that interact with CDT, we cannot assume everything will just work because CDT has a small SR release. So we will need to keep on testing each release. Now, we are discussing adding a forth release each year. That's another test cycle. That's more work.
I have other concerns (e.g., will users know to go fetch an un-aligned December release, compared to getting the release automatically with the SRs?), but let's focus on the ones above first.
We should focus on the benefits to the community, and my points might seem focused on Ericsson. In truth that is not the case. I still don't see the extra benefit to the community in having a December release compared to one at SR1 and one at SR2. Both allow the community to get features faster. If the SR1 cycle is too short, then the SR2 one comes shortly after; how is that different than a December release?
I do see a disadvantage to the community in the fact that if the committers are tied-up doing release efforts, we spend less time fixing bugs and working on features. So I believe it is a direct benefit to the community to minimize the overhead of the committers.
The only question mark for me is the release review. I am not familiar with it and don't understand how much work that entails. But besides that, I believe that not being aligned with the release train will slow us down with a benefit I have yet to understand.
But I'm enjoying the discussion :)
Marc
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Doug Schaefer [dschaefer@xxxxxxx]
Sent: August 13, 2014 2:00 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Releases
Thanks everyone. I'd iike to hear from the Ericsson gang before going much further.
To answer some of the questions below, IMHO, this is actually less releases than what we were planning. The SR's are now just maintenance releases which are a lot less work (no release review required, for example). We go from 3 minor releases a year to 2 which allows us to make each one more feature rich and gives us enough time to test them.
And, yes, sorry for the late call with 8.4.1. I was always worried about the 4 month cycle (which is actually only 3 with SR-1) and should have held my ground there. It will mean more work for folks like Jeff who want to get things in the SR.
If we decide this is the way to go, we'll need to firm up the 8.5 schedule. I don't mind doing it early in December, which is really only 2 months after SR-1, so if there are things that can wait that long, you wouldn't need to post it to the SR.
The more I think about having a holiday season release, the more I like it. Especially with the personal work I'm doing with Wascana supporting hobbyists on Windows and Arduino (and maybe even Raspberry Pi). It would be nice to get this all into their hands by then.
Doug.
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Sergey Prigogin [eclipse.sprigogin@xxxxxxxxx]
Sent: Wednesday, August 13, 2014 1:18 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Releases
I'm OK with either proposed of the current release schedule. We are releasing approximately twice a month from nightly builds, so it doesn't make a difference for us.
-sergey
On Mon, Aug 11, 2014 at 11:10 AM, Doug Schaefer <dschaefer@xxxxxxx> wrote:
Hey gang,
I'm back in Ottawa but on vacation for the rest of the week. But I didn't want this conversation to die without a conclusion, especially with Luna SR-1 so close.
Unless someone has something on master they really want to get into Luna SR-1, I propose the following schedule.
September - Luna SR-1. CDT 8.4.1 off of the 8.4 branch. Cherry pick any important fixes you have on master to the branch.
first half of December - CDT 8.5 from master. Just in time for the holiday season. We would make sure that Luna SR-1 users can upgrade to it.
February - Luna SR-2. CDT 8.5.1 fixes from the 8.5 branch.
June - Mars. CDT 8.6.
I think the 6 month cycle would really help get quality features in each release. It also reduces the number of release reviews we need to do :).
Thoughts?Doug.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev