Ridiculous

[SquirrelAssassin]

There are breaking changes every few months with azure modules for powershell now your telling us there your going to stop supporting azure rm. Go ahead tell a .net developer that they have to change there code every year .... you know what they are going to say ... I'm going to go learn Java. You guys gotta stop this.

[markcowl]

@SquirrelAssassin Agreed that breaking changes are always painful. We have taken quite a few steps to limit customer exposure to breaking changes despite a rapidly changing API surface for Azure, including:

• Breaking changes are limited to at maximum 2 releases per year (Spring around BUILD and Fall)
• We use semantic versioning for each module, so that you can know whether a module update will contain breaking changes by looking at the major version
• We maintain backward compatibility in the Az.Accounts module, so that you can mix versions of individual modules if you don't want to take a breaking change
• We provide thorough descriptions of breaking changes and required code changes in our migration guides
• We require breaking changes to be preceded by at least 4 releases with a deprecation notice that appears when you execute cmdlets

In the case of Az, this is actually a new product -it supports PowerShell Core, and Windows PowerShell, and for Windows PowerShell, requires an update to .Net 4.7.2 or higher to support NetStandard 2.0. For this reason and other it is a new module, however, the biggest breaking changesare simply the module names, and the vast majority of users report that after runnign Enable-AzureRmAlias and adjusting imports for the new module names, they are able to run their AzureRM scripts without modification. You can see complete details on migration here

We also have plans in the upcoming year to expand suppoirt for API Profiles, so that those who are concerned with API changes can opt out of any API changes for 2 years or more.

Meanwhile, if there is anything that we can do to help minimize the impact of breaking changes, let you know about how changes impact your scripts (or anythign else on this subject that would be helpful), please let us know

[SquirrelAssassin]

Lets go down a story book line here: Once upon a time in 2019 Jimmy wrote code using azurerm, a lot of it. Behind the scenes big brother MS was working hard on a new platform rather then fixing their current one because they didn't come together to fully understand how to future proof their initial work by making modular code modular. Forcing a "new product".
Fast forward to 2021, new management is here, hooray! There is some production issue and management saw a revenue loss. Management reviews Jimmy's code that he hacked "fixed" because he was super busy with other things. Management sees 'enable-azurermalias' command and azurerm calls all over the place and freaks out. Management goes to Jimmy and says you will have to rewrite all of this as fast as possible due to using all outdated and unsupported code. Jimmy says well MS said it should work. Management again shrugs there shoulders, we have no way to prove it and MS will not support it.

Poor Jimmy looses time with his kids, family, and beloved dog, as he's now be heads down for weeks to re-write code.

Moral of the story, the more breaking changes / "new products", the more time people will lose with their family and friends.

[markcowl]

@SquirrelAssassin Design issues aside, it was our intention that, at the beginning of 2019, it would be obvious to Azure PowerShell users that they should be doing new development in Az. If this was not the case for you, then we should explore how we could have made this information more clear.

I am not sure what is meant by Microsoft not supporting Enable-AzureRmAlias and the old command names - we absolutely support and, and would fix incompatibility issues you found outside the migration guide. If this information is not clear, then, again, we should explore how to make this more clear.

[SquirrelAssassin]

https://docs.microsoft.com/bs-latn-ba/azure/sql-database/scripts/sql-database-sync-update-schema "This article has been updated to use the new Azure PowerShell Az module. You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020." This still means you will still support the old commands?

I would also suggest go out to all the sites with AzureRM examples... and put a warning on ALL of the pages saying MS gave up on Azure RM, stop looking here ... go to XYZ site for what you should be using.

I have not seen a single email on any of this. Office365 sends out 5 emails a week at least, if they can send out emails, the Azure PowerShell team should send out at least one email to tenant GA's.

The only way I found out about this is by looking for the way to enable MSI on Function Apps, and saw this new format for code.

[markcowl]

This did go to the Azure MVPs alias last year, and was on the Azure blog a couple of times. We don't collect email addresses from our users, @dcaro will know whether we have other channels for communication with indidual users directly.

If there is another blog / group alias / twitter that would be more likely to get to you, please let us know.

The documentation went through a phased update starting last December, and we have heard that the phased documentation roll out was confusing from several MVPs. We will certainly learn from this the next time there is a big update.

[markcowl]

I think we have heard the complaint about developer notification - if there are additional feedbacks, please open a new issue - resolving this oen for now.