Drop old language versions support in Functions v4

[AnatoliB]

In Functions v4, drop support for the following language versions:

• Node.js
  • Version 10
    • Community EOL: April 30, 2021
  • Version 12
    • Community EOL: April 30, 2022
• PowerShell
  • Version 6
    • Community EOL: September 4, 2020
• Python
  • Version 3.6
    • Community EOL: December 23, 2021

All these versions are currently supported by Functions v3, and they must continue being supported until the date promised by Azure Functions, even if this date exceeds the community EOL date. This promise, however, does not imply that these language versions must be supported by Functions v4 as well. As long as Functions v3 is not deprecated, it serves the purpose of fulfilling the promise. So, it is important to make sure that Functions v3 is not deprecated earlier than the end of support dates for each mentioned language version.

Here is how the result will look like:

Language	v1	v2	v3	v4
Java	N/A	8	11, 8	11, 8
Node.js	6	10, 8	14, 12, 10	161, 14
PowerShell	N/A	6	7.0, 6	7.21, 7.0
Python	N/A	3.7, 3.6	3.91, 3.8, 3.7, 3.6	3.101, 3.91, 3.8, 3.7

¹ Support of these versions in Azure Functions is expected by the end of 2021

When migrating Functions apps from v3 to v4, users will have to explicitly specify a new language version and review, test, and potentially modify their code.

See also:

• Azure Functions language runtime support policy | Microsoft Docs
• Supported languages in Azure Functions | Microsoft Docs
• Internal: Support and Deprecation Policies for Azure Functions.docx

Motivation

• Reduce maintenance burden for Azure Functions engineers.
• Reduce the footprint of language workers to make them more effiecient.
• Encourage users to migrate to supported language versions.

Impact

Functions v3 stats:

• Node.js
  • Version 10: ~22% of apps
  • Version 12: ~37% of apps
• PowerShell
  • Version 6: ~34% of apps
• Python
  • Version 3.6: ~17% of apps

Compat-mode support

Introducing a feature flag to enable old language versions in Functions v4 would defeat the purpose of the change.

Alternatives

Alternative 1: Do not drop support of old language versions

Keeping support for old language versions in Functions v4 would mean not getting the benefits described in Motivation.

Alternative 2: Auto-migrate apps to newer language versions

Language owners frequently introduce breaking changes in newer language versions. As a result, some Functions app code is expected to either stop working or produce unexpected and undesired behavior. In order to attract users attention to this fact and invite them to review and test their code, we should make sure the language version upgrade is performed by users explicitly.

Alternative 3: Drop support for older language versions even more aggressively

• Java
  • We cannot drop Java 8 as the vast majority of Functions Java apps use this version, and they are expected to use it for the foreseeable future.
• Node.js
  • We cannot drop Node.js 14 because its community EOL is April 30, 2023, which is later than the projected Functions v3 deprecation date.
• PowerShell
  • We cannot drop PowerShell 7.0 because PowerShell 7.2 support cannot be added by the expected Functions v4 GA release date, so dropping 7.0 would mean that Functions v4 would GA without any version of PowerShell.
• Python
  • We cannot drop Python 3.7 because its community EOL is June 27, 2023, which is later than the projected Functions v3 deprecation date.

Detection

• Functions Host and language workers already emit error messages on invalid language versions.
• We should also make sure we have detectors notifying of this error and providing migration guidance.

Support

Support needs to be aware of the language version support matrix.

Documentation

The following documentation will need to be updated:

• Supported languages in Azure Functions | Microsoft Docs
• Node version
• PowerShell versions
• Python version

Components impacted

• Language workers
• Stacks API definition
• Tooling
  • Az CLI
  • Az PowerShell

Performance

No performance impact.

[AnatoliB]

Discussion: #2004

[brettsam]

Related: Azure/azure-powershell#15919

[brettsam]

@AnatoliB -- can you fill in status of each language here so we can track?

[AnatoliB]

• Host and language workers:
  • Windows
    • Node.js: if a v3 app on an old Node.js version is migrated to v4, the Node.js worker will report the error:
      • V4 only supports Node14 azure-functions-nodejs-worker#416
      • Upgrading NodeJsWorker to 4.0.0 azure-functions-host#7704
    • PowerShell: the supported versions are defined in the worker.config.json file; if a v3 app on an old PowerShell version is migrated to v4, the Host will report the error
    • Java and Python: N/A
  • Linux
    • All languages: if a v3 app on an old language version is migrated to v4, we'll fail to find a placeholder in the pool, which will lead to a 503 (no workers available) when pinging the site, but no clear message that this language version isn't supported.
      • TODO: improve either the message or the diagnostic tools/docs. This is decoupled from the Host release, as the Host does not get a chance to handle this better anyway.

The following updates are decoupled from the Host release cadence:

• Stacks API definition:
  • AB#11307243 Proposed functions stacks API changes for V4 GA azure-functions-ux#6289
• Tools:
  • Azure CLI:
    • in progress: functionapp: Add support for .NET 6 stacks azure-cli#19407
  • Azure PowerShell:
    • in progress: Update Stacks API with the list of supported languages in Functions V4 azure-powershell#15919