docs: propose dedicated AKS release process #2046
Conversation
| - e.g., we cut a new AKS release branch from AKS Engine the latest v0.41 release | ||
| - Any additional commits in AKS Engine ahead of this new AKS release branch that are desired by AKS immediately will be cherry-picked by AKS into the new AKS release branch. | ||
| - For the duration of the "October" release cycle, AKS continues to cherry-pick changes from `aks-engine@master` into its "October" release branch. | ||
| - When "November" arrives, AKS cuts a new release branch from AKS Engine according to the above n-1 calculation. |
There was a problem hiding this comment.
is this a typo when we say "AKS cuts new release branch from AKS Engine" here?If I remember correctly in our last discussion, AKS-Engine (but not AKS) will cut the new release in AKS Engine repo?
There was a problem hiding this comment.
In terms of requirements, AKS should drive those. So:
- Create new branch from commit @ AKS-Engine n-1 release
- Cherry-pick any desired changes after the above commit
- Publish a release
I think AKS and AKS Engine will do the above in tandem. Especially #2 AKS will drive, and especially #3 AKS Engine will do.
Does that make sense? I think the details will probably look something like that, do we want to clarify that in the doc?
There was a problem hiding this comment.
yes makes sense. since we're here, it can help others to understand the process better, if we can just put what you added into the doc.
There was a problem hiding this comment.
Do we need to do 3? From the doc it seems like we only cut a release branch without publishing an actual release which makes sense to me since these AKS specific changes don't always apply to aks-engine users who might be tracking releases to use the latest patch.
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jackfrancis, xuto2 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 |
|
|
||
| - Additional testing/validation will be required for the monthly "catch-up" AKS releases. This additional validation overhead will be scheduled so as not to slow down feature and bugfix velocity during these intervals. | ||
| - I.e., these releases will include _all_ AKS Engine changes at the AKS Engine minor release that AKS derives its new release from, not just AKS-specific changes | ||
| - All AKS-targeted changes to AKS Engine will be introduced via the normal PR-against-master workflow. In other words, the AKS release channel will not be a first class commit destination for novel additions/deletions to code; all changes will be cherry-picked from master. |
|
Can you add a note about always publishing a VHD from that release branch to ensure that component versions pre-installed match the ones in code? Also, let's add a new release process check to run the no-outbound test on every release/branch/tag before vendoring it to AKS. |
+1 on this With that, sometimes we may need to publish a VHD specifically for AKS(with or without "aks" in the vhd release name). I assume this is compatible with current AKS engine release policy? |
|
Blocked by #2245 |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
keep open |
Reason for Change:
This PR proposes a new, dedicated AKS release process.
Issue Fixed:
Requirements:
Notes: