You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Leif Hedstrom <zw...@apache.org> on 2017/04/21 23:06:20 UTC
[PROPOSAL] New ATS release process and schedule
Hi all,
I’d like to propose a drastic change to how we manage releases, and how often. It all boils down to the fact that we are not equipped to test, manage and deploy 3x releases / year. So, attached below is the new, proposed release schedule, as well as a picture showing an example git branch layout (thanks Masakazu!).
What does this mean? Well, here are some highlights:
1. We only schedule one main release / year (starting with 7.1.x this year in May). Each main release branch is 2 years LTS.
2. A release branch is cut off master once a year, meaning, master is always open for any change. This does not mean that master is unstable, everything we commit must work, be tested and reviewed etc. (that is not changing!).
3. The community can agree to make a minor release, e.g. v7.2.0 at any given time during the 7.x 2 year life cycle. Such a release is still branched off the 7.x branch, and *not* master as before. Any such point release is also LTS, for up to 2 years (same 2 year period as the branch itself).
4. The RM + community agrees on which commits from master should go into a minor release. This would be for example a new feature, or a new plugin etc. Critical crashes / security fixes is dealt with as normal with a patch release.
4. Critical fixes (e.g. security fixes) on an LTS branch must be applied to every LTS minor release on that branch. As an example, this could mean making a v7.1.1 release as well as a v7.2.1 release.
5. We are somewhat off schedule right now, so the proposal is to make 7.1.x the 7.x LTS branch, and we’ll support this for 2 years. 7.0.x is not LTS and will not be supported once v7.1.0 is released.
6. We will not schedule a v7.2.0 release for July, nor an v8.0.0 release for October. Instead, after v7.1.0 is released, the next scheduled release is v8.0.0, in May 2018.
I’m volunteering to RM this first 7.x release, with Bryan Call assisting on minor and patch releases.
Cheers,
— leif
The new release schedule and images are on
https://cwiki.apache.org/confluence/display/TS/Updated+Release+Management <https://cwiki.apache.org/confluence/display/TS/Updated+Release+Management>
I will move this to the official release page once we agree this is the way we want to move forward.
Re: [PROPOSAL] New ATS release process and schedule
Posted by Bryan Call <bc...@apache.org>.
+1
-Bryan
> On Apr 25, 2017, at 8:02 AM, Leif Hedstrom <zw...@apache.org> wrote:
>
>
>> On Apr 21, 2017, at 5:06 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>
>> Hi all,
>>
>> I’d like to propose a drastic change to how we manage releases, and how often. It all boils down to the fact that we are not equipped to test, manage and deploy 3x releases / year. So, attached below is the new, proposed release schedule, as well as a picture showing an example git branch layout (thanks Masakazu!).
>
>
> There’s been no negative feedback on this, so I’m going to do this. We’ll present this at the summit as well, but the next steps are:
>
> 1) Mark current master as “v8.0.0”.
>
> 2) Finish the 7.1.x release, which will be LTS. Release date TBD, but likely mid May.
>
> 3) After this, I’ll make a new 7.x branch, identical to the 7.1.x release branch (at the time of release).
>
>
> Going forward, any 7.2.0 release would be cherry picks from master to the new 7.x release branch. But there is no scheduled 7.2.x release at this point. v8.0.0 is the next officially scheduled release, for May 2018.
>
> Cheers,
>
> — leif
>
>
Re: [PROPOSAL] New ATS release process and schedule
Posted by Bryan Call <bc...@apache.org>.
+1
-Bryan
> On Apr 25, 2017, at 8:02 AM, Leif Hedstrom <zw...@apache.org> wrote:
>
>
>> On Apr 21, 2017, at 5:06 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>
>> Hi all,
>>
>> I’d like to propose a drastic change to how we manage releases, and how often. It all boils down to the fact that we are not equipped to test, manage and deploy 3x releases / year. So, attached below is the new, proposed release schedule, as well as a picture showing an example git branch layout (thanks Masakazu!).
>
>
> There’s been no negative feedback on this, so I’m going to do this. We’ll present this at the summit as well, but the next steps are:
>
> 1) Mark current master as “v8.0.0”.
>
> 2) Finish the 7.1.x release, which will be LTS. Release date TBD, but likely mid May.
>
> 3) After this, I’ll make a new 7.x branch, identical to the 7.1.x release branch (at the time of release).
>
>
> Going forward, any 7.2.0 release would be cherry picks from master to the new 7.x release branch. But there is no scheduled 7.2.x release at this point. v8.0.0 is the next officially scheduled release, for May 2018.
>
> Cheers,
>
> — leif
>
>
Re: [PROPOSAL] New ATS release process and schedule
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 21, 2017, at 5:06 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> Hi all,
>
> I’d like to propose a drastic change to how we manage releases, and how often. It all boils down to the fact that we are not equipped to test, manage and deploy 3x releases / year. So, attached below is the new, proposed release schedule, as well as a picture showing an example git branch layout (thanks Masakazu!).
There’s been no negative feedback on this, so I’m going to do this. We’ll present this at the summit as well, but the next steps are:
1) Mark current master as “v8.0.0”.
2) Finish the 7.1.x release, which will be LTS. Release date TBD, but likely mid May.
3) After this, I’ll make a new 7.x branch, identical to the 7.1.x release branch (at the time of release).
Going forward, any 7.2.0 release would be cherry picks from master to the new 7.x release branch. But there is no scheduled 7.2.x release at this point. v8.0.0 is the next officially scheduled release, for May 2018.
Cheers,
— leif
Re: [PROPOSAL] New ATS release process and schedule
Posted by Leif Hedstrom <zw...@apache.org>.
> On Apr 21, 2017, at 5:06 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> Hi all,
>
> I’d like to propose a drastic change to how we manage releases, and how often. It all boils down to the fact that we are not equipped to test, manage and deploy 3x releases / year. So, attached below is the new, proposed release schedule, as well as a picture showing an example git branch layout (thanks Masakazu!).
There’s been no negative feedback on this, so I’m going to do this. We’ll present this at the summit as well, but the next steps are:
1) Mark current master as “v8.0.0”.
2) Finish the 7.1.x release, which will be LTS. Release date TBD, but likely mid May.
3) After this, I’ll make a new 7.x branch, identical to the 7.1.x release branch (at the time of release).
Going forward, any 7.2.0 release would be cherry picks from master to the new 7.x release branch. But there is no scheduled 7.2.x release at this point. v8.0.0 is the next officially scheduled release, for May 2018.
Cheers,
— leif