Gearing up for 1.0 release

[Tim Hockin]

As we come up on 1.0, we need to stabilize the codebase.  I propose the following, please argue with me if you think it is wrong. Obviously this is "ideal" and there will be exceptions.

Wed 10/21:

  * Code-complete for breaking changes

  * Code-slush begins on `main`

    - Only bugfixes, stability, tests will be merged

    - Any exceptions MUST be approved by ONE of Ben, Dima, Eitan, Tim

    - Anything else will be reverted

  * Cut release-0.6 branch

                                                                                                                                       

Wed 10/28:

  * Code-slush on `main` intensifies

    - Only P0 bugfixes, stability, tests will be merged

    - Any exceptions MUST be approved by TWO of Ben, Dima, Eitan, Tim

    - Anything else will be reverted

  * Cut release-0.7 branch

Tue 11/3 - 11/9:

  * Code-freeze on `main`

    - Only CRITICAL P0 bugfixes, stability, and tests will be merged

    - All merges MUST be approved by THREE of Ben, Dima, Eitan, Tim

    - Anything else will be reverted

  * Daily RC builds

When possible:

  * GA

  * Cut release-1.0 branch from last RC

  * Tag 1.0.0

* Rest

[Taahir Ahmed]

I would propose not slowing main, since there is a lot of "deferred from GA" feature and polish work that doesn't break backcompat that people are going to want to land.

Definitely the bar should go up for backwards-incompatible changes.  But slowing main at this time is going to kill a lot of momentum, and risks establishing one of the more frustrating mistakes of the Kubernetes project (missing a release window is very high cost, so people fight hard to get their feature into any given release).

We should cut the release branch that is going to become 1.0, and put any stabilization work there (and main, if necessary).

--
You received this message because you are subscribed to the Google Groups "ate-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ate-dev+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ate-dev/CAO_RewYtf8_prv1%2BJhPCLg7stxhthO8qq1Y5ai00e1dtBW5PWA%40mail.gmail.com.

[Eitan Yarmush]

Great point Taahir.

I agree that we should not block forward movement completely, and cutting a release candidate branch sounds like a great way to do that.

One note is that if we cut a release branch it means all GA work will need to be backported, probably adding time to each step. 

I definitely want to avoid the kubernetes problem you mentioned, but I also wonder if GA is a bit of a special case. 

The other issue is that it will be all hands on deck for reviews, so we need to make sure everything related to GA is reviewed more quickly.

Thoughts?

To view this discussion visit https://groups.google.com/d/msgid/ate-dev/CAC%3DMKY8WJT5qs9-m5TeLNHb2e8JtKa2XdeykDqcxNt%2BJXq_Nag%40mail.gmail.com.

[Tim Hockin]

Eitan's response was my thinking.  I don't see any real value in making all fixes send 2 PRs, and even less value in them being DIFFERENT (assuming anything substantial lands on main).  It seems like all downside and almost no upside.

I could maybe buy it on 10/28 (cut release-1.0 instead of 0.7) but nobody should have time to be merging other changes into main anyway, so is it really worthwhile? 

Or we could do that on 11/3, so any RC is currently from the release-1.0?

[Benjamin Elder]

> I definitely want to avoid the kubernetes problem you mentioned, but I also wonder if GA is a bit of a special case. 

Yes. I agree that we don't want to stick to "main is blocked, big code freeze" every time, but 0.X => 1.0 feels different.

The first time we're trying to introduce backcompat, harden everything, and get ahead of KubeCon promotion => first impressions "why is X broken".

> The other issue is that it will be all hands on deck for reviews, so we need to make sure everything related to GA is reviewed more quickly.

That and CI bandwidth.

To view this discussion visit https://groups.google.com/d/msgid/ate-dev/CAO_RewagOVH188-kxHGF5%2Bc8SqgXFw_QpEp1Zw3Yoh9i_ENxuQ%40mail.gmail.com.

[Tim Hockin]

OK, I'll propose a revision.  The main change is that we create the 1.0 release branch and RC1 on 10/28 (or 10/29?).

Wed 10/21:
  * Code-complete for breaking changes
  * Code-slush begins on `main`

    - Only merge PRs for: bugfixes, stability, or security, plus tests and docs

    - Any exceptions MUST be approved by ONE of Ben, Dima, Eitan, Tim

    - Anything else that slips through will be reverted
  * Create a `release-0.6` branch

  * Cut a `v0.6.0` release

  * Development continues on `main`

    - Other PRs may be opened but not merged                                                                             

Wed 10/28:
  * Code-slush on `main` intensifies

    - Only merge PRs for: P0 bugfixes, stability, or security, plus tests and docs 

    - Any exceptions MUST be approved by TWO of Ben, Dima, Eitan, Tim

    - Anything else that slips through will be reverted
  * Create a `release-1.0` branch

  * Cut a `v1.0.0-rc1` release

  * Development happens on `main`, but ALL merges MUST be cherry-picked to `release-1.0`

    - Why: By definition, any RC release *might* become `v1.0.0`, so it should come from the release branch

    - Other PRs may be opened but not merged                                                                             

Tue 11/3 - 11/9:
  * Code-freeze on `main`

    - Only merge PRs for: CRITICAL P0 bugfixes, stability, or security, plus tests and docs

    - All merges MUST be approved by THREE of Ben, Dima, Eitan, Tim

    - Anything else that slips through will be reverted
  * Daily RC builds from `release-1.0` branch
    - Other PRs may be opened but not merged                                                                             

When possible:
  * GA
  * Cut a `v1.0.0` release from last RC

  * Code-freeze on `main` ends in T+2 days.
  * Rest

[Tim Hockin]

New iteration, hopefully clearer

Thu 10/22:

  * Code-complete for breaking changes
  * Code-slush begins on `main`

    - Only merge PRs for: bugfixes, stability, or security, plus tests and docs

      - PRs for bugfixes, stability, or security MUST be approved by ONE of Ben, Dima, Eitan, Tim

      - PRs for tests, benchmarks, docs DO NOT need special approval

      - Any exceptions MUST be approved by ONE of Ben, Dima, Eitan, Tim
      - Anything else that slips through will be reverted
  * Create a `release-0.6` branch
  * Cut a `v0.6.0` release
  * Development continues on `main`
    - Other PRs may be opened but not merged                                                                            

Wed 10/28:
  * Code-slush on `main` intensifies
    - Only merge PRs for: P0 bugfixes, stability, or security, plus tests and docs

      - PRs for bugfixes, stability, or security MUST be approved by TWO of Ben, Dima, Eitan, Tim

      - PRs for tests, benchmarks, docs DO NOT need special approval

      - Any exceptions MUST be approved by TWO of Ben, Dima, Eitan, Tim  
      - Anything else that slips through will be reverted

  * Create a `release-1.0` branch

    - All PRs MUST be cherry-picked to this branch

  * Cut a `v1.0.0-rc1` release
  * Development happens on `main`, but ALL merges MUST be cherry-picked to `release-1.0`
    - Why: By definition, any RC release *might* become `v1.0.0`, so it should come from the release branch
    - Other PRs may be opened but not merged                                                                            

Tue 11/3 - 11/9:
  * Code-freeze on `main`
    - Only merge PRs for: CRITICAL P0 bugfixes, stability, or security, plus tests and docs

      - ALL PRs MUST be approved by THREE of Ben, Dima, Eitan, Tim

      - Anything else that slips through will be reverted

  * All PRs MUST be cherry-picked to the `release-1.0` branch

  * Daily RC builds from `release-1.0` branch
    - Other PRs may be opened but not merged                                                                            

When possible:
  * GA
  * Cut a `v1.0.0` release from last RC
  * Code-freeze on `main` ends in T+2 days.
  * Rest