Release planning

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Release planning

Doug Schaefer-3
Hey gang,

I’m just looking ahead on how to manage releases for the next while and would like your thoughts on it.

I have always thought releasing every three months just didn’t give us enough time to get the job done right, especially over the summer months. I think our Oxygen plan where we skipped Neon.3 really helped us focus.

As a result, I’d like us to continue with a 6 month release cycle. That would make 9.4 in December for Oxygen.2, and 9.5 for Photon next June and so on.

We can do maintenance releases any time and it probably makes sense to at least do ones for the .1 and .3 Eclipse releases.

Thoughts?
Doug.

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Release planning

Doug Schaefer-3
BTW, when I say release every 6 months, I mean minor release where we are allowed to add functionality and APIs.

From: <[hidden email]> on behalf of Doug Schaefer <[hidden email]>
Reply-To: "CDT General developers list." <[hidden email]>
Date: Tuesday, May 16, 2017 at 11:14 AM
To: "CDT General developers list." <[hidden email]>
Subject: [cdt-dev] Release planning

Hey gang,

I’m just looking ahead on how to manage releases for the next while and would like your thoughts on it.

I have always thought releasing every three months just didn’t give us enough time to get the job done right, especially over the summer months. I think our Oxygen plan where we skipped Neon.3 really helped us focus.

As a result, I’d like us to continue with a 6 month release cycle. That would make 9.4 in December for Oxygen.2, and 9.5 for Photon next June and so on.

We can do maintenance releases any time and it probably makes sense to at least do ones for the .1 and .3 Eclipse releases.

Thoughts?
Doug.

_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Release planning

Jonah Graham
(we have been having some discussion on mattermost[1] about this)

I vote +1 to the every 6 months. As always if a significant feature
comes along (like more improvements to C++14) we can revise the
release plan to get these improvements into user's hands sooner.

[1] https://mattermost.eclipse.org/eclipse/pl/6bnh9qm94ib5jxfug7xz9fzphe
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com


On 16 May 2017 at 16:17, Doug Schaefer <[hidden email]> wrote:

> BTW, when I say release every 6 months, I mean minor release where we are
> allowed to add functionality and APIs.
>
> From: <[hidden email]> on behalf of Doug Schaefer
> <[hidden email]>
> Reply-To: "CDT General developers list." <[hidden email]>
> Date: Tuesday, May 16, 2017 at 11:14 AM
> To: "CDT General developers list." <[hidden email]>
> Subject: [cdt-dev] Release planning
>
> Hey gang,
>
> I’m just looking ahead on how to manage releases for the next while and
> would like your thoughts on it.
>
> I have always thought releasing every three months just didn’t give us
> enough time to get the job done right, especially over the summer months. I
> think our Oxygen plan where we skipped Neon.3 really helped us focus.
>
> As a result, I’d like us to continue with a 6 month release cycle. That
> would make 9.4 in December for Oxygen.2, and 9.5 for Photon next June and so
> on.
>
> We can do maintenance releases any time and it probably makes sense to at
> least do ones for the .1 and .3 Eclipse releases.
>
> Thoughts?
> Doug.
>
>
> _______________________________________________
> cdt-dev mailing list
> [hidden email]
> 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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Release planning

Doug Schaefer-3
Thanks Jonah, we could be more agile about it. If we get a contribution
that needs a release review we can call for a minor release at any time
(though preferably on a Eclipse release boundary). I don¹t mind that.

I really just wanted to make sure people aren¹t assuming there will be a
guaranteed minor release in September, unless we need one.

On 2017-05-16, 12:07 PM, "[hidden email] on behalf of Jonah
Graham" <[hidden email] on behalf of [hidden email]>
wrote:

>(we have been having some discussion on mattermost[1] about this)
>
>I vote +1 to the every 6 months. As always if a significant feature
>comes along (like more improvements to C++14) we can revise the
>release plan to get these improvements into user's hands sooner.
>
>[1] https://mattermost.eclipse.org/eclipse/pl/6bnh9qm94ib5jxfug7xz9fzphe
>~~~
>Jonah Graham
>Kichwa Coders Ltd.
>www.kichwacoders.com
>
>
>On 16 May 2017 at 16:17, Doug Schaefer <[hidden email]> wrote:
>> BTW, when I say release every 6 months, I mean minor release where we
>>are
>> allowed to add functionality and APIs.
>>
>> From: <[hidden email]> on behalf of Doug Schaefer
>> <[hidden email]>
>> Reply-To: "CDT General developers list." <[hidden email]>
>> Date: Tuesday, May 16, 2017 at 11:14 AM
>> To: "CDT General developers list." <[hidden email]>
>> Subject: [cdt-dev] Release planning
>>
>> Hey gang,
>>
>> I¹m just looking ahead on how to manage releases for the next while and
>> would like your thoughts on it.
>>
>> I have always thought releasing every three months just didn¹t give us
>> enough time to get the job done right, especially over the summer
>>months. I
>> think our Oxygen plan where we skipped Neon.3 really helped us focus.
>>
>> As a result, I¹d like us to continue with a 6 month release cycle. That
>> would make 9.4 in December for Oxygen.2, and 9.5 for Photon next June
>>and so
>> on.
>>
>> We can do maintenance releases any time and it probably makes sense to
>>at
>> least do ones for the .1 and .3 Eclipse releases.
>>
>> Thoughts?
>> Doug.
>>
>>
>> _______________________________________________
>> cdt-dev mailing list
>> [hidden email]
>> 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
>[hidden email]
>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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Release planning

Nathan Ridge
In reply to this post by Doug Schaefer-3
In addition to the consideration of getting features in front of users sooner, which Jonah has touched on, I have found having two active branches and having to backport bugfixes to the old branch (which I want to do, to get bugfixes in front of users sooner) to be a fair deal of overhead, so from that point of view I think more frequent releases (and in particular, only having one active branch at a time) are better.

To be fair, I don't have a good measure of the amount of overhead / extra work involved in putting out a release, so it could be that that's the more significant consideration.

Regards,
Nate
________________________________________
From: [hidden email] <[hidden email]> on behalf of Doug Schaefer <[hidden email]>
Sent: May 16, 2017 3:14 PM
To: CDT General developers list.
Subject: [cdt-dev] Release planning

Hey gang,

I’m just looking ahead on how to manage releases for the next while and would like your thoughts on it.

I have always thought releasing every three months just didn’t give us enough time to get the job done right, especially over the summer months. I think our Oxygen plan where we skipped Neon.3 really helped us focus.

As a result, I’d like us to continue with a 6 month release cycle. That would make 9.4 in December for Oxygen.2, and 9.5 for Photon next June and so on.

We can do maintenance releases any time and it probably makes sense to at least do ones for the .1 and .3 Eclipse releases.

Thoughts?
Doug.
_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Release planning

Nathan Ridge
> I have found having two active branches and having to backport
> bugfixes to the old branch (which I want to do, to get bugfixes in
> front of users sooner) to be a fair deal of overhead

This also means that *if* we're going to have a 9.4 release for
Oxygen.1, it would be good to decide that now (or by the time
9.3 branches), so that we don't waste time backporting fixes
to the 9.3 branch in that case.

Regards,
Nate
_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Release planning

Doug Schaefer-3
In reply to this post by Doug Schaefer-3
On 2017-05-16, 3:19 PM, "[hidden email] on behalf of Nathan
Ridge" <[hidden email] on behalf of [hidden email]>
wrote:

>> I have found having two active branches and having to backport
>> bugfixes to the old branch (which I want to do, to get bugfixes in
>> front of users sooner) to be a fair deal of overhead
>
>This also means that *if* we're going to have a 9.4 release for
>Oxygen.1, it would be good to decide that now (or by the time
>9.3 branches), so that we don't waste time backporting fixes
>to the 9.3 branch in that case.

+1 We don¹t have the capacity to have two active branches. So I¹m all for
that.

We could look at it another way. Let¹s say the maintenance releases are
for hot fixes only. Things that users are really complaining about.
Hopefully there are only a few of those. Regular bugs would go on master
only. And we would release the hot fixes any time, just as we did for
9.2.2. We would just roll up the latest hot fix release in with Oxygen.1.

I still worry whether we have the capacity to do features at three month
intervals and whether our users and vendors have the capacity to deal with
new feature releases that often. I just feel six months is more practical
and is a common cadence we see in other projects (e.g. Ubuntu). But I can
be persuaded by your (the committers') confidence in making it work :)


>
>Regards,
>Nate
>_______________________________________________
>cdt-dev mailing list
>[hidden email]
>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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev