Updated the Android and iOS release notes for the February 2021 release. #2401
Conversation
vcolin7
requested review from
alzimmermsft,
jeremymeng,
kinelski,
kyle-patterson,
Mohit-Chakraborty,
ShivangiReja and
xiangyan99
as code owners
| ```ruby | ||
| // Insert dependencies here | ||
| platform :ios, '12.0' | ||
|
|
||
| # Comment the next line if you don't want to use dynamic frameworks | ||
| use_frameworks! | ||
|
|
||
| target 'MyTarget' do | ||
| pod 'AzureCommunication', '~> 1.0.0-beta.8' | ||
| pod 'AzureCommunicationCalling', '~> 1.0.0-beta.8' | ||
| pod 'AzureCommunicationChat', '~> 1.0.0-beta.8' | ||
| ... | ||
| end | ||
| ``` |
There was a problem hiding this comment.
Why isn't this part of the standard template? That's not something we are going to copy/paste every release.
There was a problem hiding this comment.
For other languages it's not there because some packages might not be releasing every cycle. Even if iOS is releasing everything together, should we add all currently available packages every time in the release notes or only those mentioned specifically in the current month's notes?
|
Let's consolidate mine with yours. I'll just revert mine for iOS. Mine is not complete at all. |
| ### _Package name_ | ||
| ### Azure Communication Services Common | ||
|
|
||
| #### 1.0.0-beta.5 ([Changelog](https://github.com/Azure/azure-sdk-for-android/blob/master/sdk/communication/azure-communication-common/CHANGELOG.md#100-beta5-2021-02-08)) |
There was a problem hiding this comment.
We should prefer using release tags instead of master to help avoid future potential breaks.
There was a problem hiding this comment.
Sometimes we want to add the release notes to azure-sdk repo one or two days before the release is done.
For example, we can call code freeze on a Fri, then create the changelog updates commit on the next Tuesday. At this point the changelog is ready to be used in azure-sdk repo. The release chain would start (core -> services -> other services) and waiting for all services to effectively ship could be too late for the expected time that we have to share the changelog for the release blog.
The only way to update the changelog and pass the verify links step is by linking to master.
There was a problem hiding this comment.
In theory we generally only publish these release notes after everything has shipped so I'd expect that release tags would be present by the time we publish. However you are correct they might not be present if you create this ahead of time, but nor will the correct anchor tags. As we move to automating this we will not even be adding these packages until they actually release so there will always be present.
What I'm trying to avoid is having to go back and fix up these master links overtime like #2378 when things move or rename.
|
Created a PR to fix the broken link #2404 |
No description provided.