Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[kubeflow 1.8] docs: add 1.8 release timeline #621

Merged
merged 3 commits into from
May 15, 2023

Conversation

DnPlas
Copy link
Contributor

@DnPlas DnPlas commented Apr 25, 2023

Adding the release timeline for 1.8 release.

TODO:

  • Add table with details upon agreement on the timeline
  • Update links for meeting, calendar, project board, and meeting notes

cc @kubeflow/release-team @jbottum

- **Friday, May 5th 2023** : Week 0 - Release team is formed
- **Monday, May 8th 2023** : Week 1 C\* - Release cycle begins
- **Friday, May 12th 2023** : Week 1 C\* - Roadmaps are finalized
- **Wednesday, Aug 16th 2023** : Week 15 C\* - Feature freeze
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just curious, what's the reason for increasing feature freeze from typical 11 weeks to 15 weeks?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used 1.7 as reference, which used 18 weeks.
The proposal of 15 weeks is the way I found as middle ground between those 18 weeks and dates that could accommodate manifest and distribution testing, plus bug fixing, and be able to get everything on time before Kubecon. This also comes from KFP feedback, as the team would be comfortable having 2.0 by then.
I can definitely change it to what the handbook says if you think 15 weeks is too much.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation! I don't have a strong preference, and it makes sense for WG leads to drive the dates if they already have planned features/releases.

Copy link
Contributor Author

@DnPlas DnPlas Apr 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me see if I can find a better middle ground between the standard 11 weeks and the feedback I've received from WG. I'll update this proposal.

- **Monday, Sept 4th 2023** : Week 18 - Distribution testing starts
- **Friday, Sept 22nd 2023** : Week 20 - Distribution testing ends
- **Monday, Sept 25th 2023** : Week 21 C\* - Pre-release bug fixing stage starts
- **Friday, Oct 6th 2023** : Week 22 - Pre-release bug fixing stage ends
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the timeline capture testing the fix? or does this mean, this is the last day to get a fix in?

Copy link
Contributor Author

@DnPlas DnPlas Apr 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this stage I was thinking of last minute bugs that could be found by the distributions, WG and/or the CI. So during these weeks I'd expect WG to merge fixes in kubeflow/manifests that will be tested on the CI and then we cut RCs if necessary.

Comment on lines 22 to 23
- **Wednesday, Aug 16th 2023** : Week 15 C\* - Feature freeze
- **Wednesday, Aug 21st 2023** : Week 16 - Manifests testing and bug fixing starts
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To better understand the proposal, what's the reason behind the 1-week gap between feature freeze and testing? Should we start testing on Aug 17 to get more time for testing and bug fixing?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the gap is there to ensure the PRs to sync manifest to Manifest repo are all merged within that timeframe.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly, feature freeze means everything in a dev state should be finalised by then, after the feature freeze, the release team alongside the WGs should ensure everything is merged in the kubeflow/manifests repo.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe adding that as a separate item would make it more verbose?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, let me clarify that.

- **Friday, May 12th 2023** : Week 1 C\* - Roadmaps are finalized
- **Wednesday, Aug 16th 2023** : Week 15 C\* - Feature freeze
- **Wednesday, Aug 21st 2023** : Week 16 - Manifests testing and bug fixing starts
- **Friday, Sept 1st 2023** : Week 17 C\* - Manifests testing and bug fixing ends
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to avoid Fridays as a deadline in general since Friday in the U.S. means it's Saturday in other countries.

Copy link
Contributor Author

@DnPlas DnPlas Apr 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, will send an updated proposal avoiding Fridays

Comment on lines 30 to 31
- **Friday, Oct 6th 2023** : Week 22 - Docs update ends
- **Wednesday, Oct 11th 2023** : Week 23 C\* - Kubeflow v1.8 Released
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the docs are published from the master branch, they must correspond to the latest release. Shouldn't we update documentation at the same time with the release?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally the content should be ready before the release, that way on release date we just have to publish.
@annajung can you confirm this information?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think I understand the question. Could you clarify what the concern is?

I'm not sure if this helps, but the docs update ends a few days before the release day to ensure that the website release branch is cut, configuration PRs are all merged, and there is time to deploy the new release branch to Netlify.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more details about versioning the website are available here https://github.com/kubeflow/kubeflow/blob/master/docs_dev/releasing.md#version-the-website

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a strong opinion. As a user I expect the documentation to reflect the latest available release. To achieve this, docs should be released together with the actual release, or right after it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gkcalat we merge docs PRs on the same day of the release, this date only means that everything should be ready before the date of the release.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think it makes sense to be closer to the release date. Maybe a day before should be the last day to merge docs, and website release process can be done during release day

Comment on lines 6 to 8
- [Calendar](https://arrik.to/kf-release-team-cal)
- [Meeting Notes](https://arrik.to/kf-release-team-notes)
- [Recordings](https://arrik.to/kf-release-team-recordings)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use vendor-neutral links?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yesss! I will be updating these once I get confirmation of which ones we'll be using, it's in my TODO list.

@zijianjoy
Copy link
Contributor

/lgtm

The timeline plan looks good to me, thank you Daniela!

@annajung
Copy link
Member

annajung commented May 3, 2023

cc @kimwnasptd @andreyvelich @johnugeorge to review

@johnugeorge
Copy link
Member

johnugeorge commented May 10, 2023

/lgtm

Thanks @DnPlas

@johnugeorge
Copy link
Member

/lgtm

@google-oss-prow google-oss-prow bot added the lgtm label May 15, 2023
@kimwnasptd
Copy link
Member

/approve

@google-oss-prow
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: DnPlas, kimwnasptd

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@google-oss-prow google-oss-prow bot merged commit 1e63e28 into kubeflow:master May 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants