Open msyyc opened 2 months ago
The old tool made a guess of when these methods were renamed...if we do this again you have to be aware that the reporting could become inaccurate in some case and then the changelog would have to be manually updated. This one is all about trade-offs...do we prefer to try to have 1 optimized message that could be inaccurate at times? Or do we want to have the 2 entries in the changelog which are still accurate but more verbose?
One more thing, if we cant make a good approximation of when a method was renamed we may still have 2 entries in the changelog.
Since the naming pattern change for non-lro to lro is fixed (both for DPG and MPG) and the logic is not complicated, I think it is worth to do. At least for MPG, I prefer 1 optimized message.
One more thing, if we cant make a good approximation of when a method was renamed we may still have 2 entries in the changelog.
Sure, this issue is mainly for begin_
pattern, not including other scenarios.
If SDK API changes from common API to Lro API, there will be
begin_
prefix added like: It is very common kind of breakings, then old breaking tool will detect it in specific https://github.com/Azure/azure-sdk-for-python/blob/77b15b570f6f8048cfc50edb89742a41845233f2/tools/azure-sdk-tools/packaging_tools/change_log.py#L186-L189 so that the changelog is more user-friendly like:I hope new tool could also have similar optimization for SDK users.