-
Notifications
You must be signed in to change notification settings - Fork 220
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
Conversation
releases/release-1.8/README.md
Outdated
- **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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
releases/release-1.8/README.md
Outdated
- **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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
releases/release-1.8/README.md
Outdated
- **Wednesday, Aug 16th 2023** : Week 15 C\* - Feature freeze | ||
- **Wednesday, Aug 21st 2023** : Week 16 - Manifests testing and bug fixing starts |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
releases/release-1.8/README.md
Outdated
- **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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
releases/release-1.8/README.md
Outdated
- **Friday, Oct 6th 2023** : Week 22 - Docs update ends | ||
- **Wednesday, Oct 11th 2023** : Week 23 C\* - Kubeflow v1.8 Released |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
releases/release-1.8/README.md
Outdated
- [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) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
/lgtm The timeline plan looks good to me, thank you Daniela! |
cc @kimwnasptd @andreyvelich @johnugeorge to review |
/lgtm Thanks @DnPlas |
cc404fc
to
5ba9d18
Compare
/lgtm |
/approve |
[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 |
Adding the release timeline for 1.8 release.
TODO:
cc @kubeflow/release-team @jbottum