Travis Oliphant, creator of NumPy and SciPy, joins Ryan to explore the development of Python as a data science tool, the evolution of these foundational libraries, and the importance of community and collaboration in open-source projects, including Travis’ current work to support sustainable open-source through the OpenTeams Incubator.

This tutorial demonstrates how to implement asynchronous authorization in a LangGraph application using Auth0 and the CIBA flow for secure, human-in-the-loop actions

We are happy to announce that cordova-app-hello-world@7.0.0 has been released. This is the default app template used when creating a new Cordova App project though Cordova CLI.

Release Highlights

The most notable changes in this release were:

• Setting the body element's box-sizing to border-box to avoid the safe-area-inset padding that caused scrolling issues
• Disabled the overscroll behavior of the root element to remove rubber-banding effects.
• Used modern, unprefixed CSS directives.
• Updated default template's package ID to org.apache.cordova.hellocordova.

Changes include:

Fixes:

• GH-98 fix(css): Fix extra padding causing scrolling

Chores:

• GH-99 chore: updated defaults, license headers & added release audit workflow
• GH-78 chore: correct access inline comment

We are happy to announce that cordova-fetch@5.0.0 has been released. This is the library used behind-the-scenes of the Cordova tooling for fetching of Cordova platforms and plugins.

Release Highlights

The most notable changes in this major release were:

• Updated the library's npm dependencies.
• Increased in the Node.js engine requirement to >=20.9.0.

Changes include:

Breaking Changes:

• GH-131 chore(npm)!: bump cordova-common@6.0.0
• GH-125 chore!: bump node requirement & npm dependencies

Chores:

• GH-136 chore(README): update badges
• GH-135 chore: update & add source code license headers
• GH-130 chore: bump @cordova/eslint-config
• GH-127 chore(coverage): Move from nyc to c8 for code coverage
• GH-124 chore(deps-dev): bump brace-expansion from 1.1.11 to 1.1.12
• GH-122 chore(deps): bump cross-spawn from 7.0.3 to 7.0.6
• GH-120 chore(deps): bump micromatch from 4.0.5 to 4.0.8
• GH-119 chore(deps): bump braces from 3.0.2 to 3.0.3
• GH-116 chore(deps): Update some dependencies, add Node 20 to CI

CI:

• GH-137 ci: workflow updates
• GH-128 ci(workflow): update release-audit & license config
• GH-123 ci: Add licence checker workflow
• GH-121 ci: Fix dependabot code scanning errors
• GH-118 ci: Set up CodeQL analysis
• GH-117 ci: update codecov@v4 w/ token

Tests:

• GH-126 test: drop file-url

We’re excited to announce that Azure Database for MySQL – Flexible Server now supports MySQL 8.4 in General Availability (GA). This means you can create new MySQL 8.4 servers on Azure fully supported for production workloads. MySQL 8.4 is a long-term supported release from the MySQL community, bringing the latest features and improvements while emphasizing stability. With Azure’s managed service, you get these new capabilities backed by Azure’s enterprise-grade reliability and support. In short, MySQL 8.4 GA opens the door for you to upgrade your databases and future-proof your MySQL environment on Azure.

Why Upgrade to MySQL 8.4?

Avoid End-of-Support Deadlines: If you’re running MySQL 5.7 or 8.0 on Azure, planning an upgrade is crucial. MySQL 5.7’s community support ended on October 31, 2023, and MySQL 8.0’s end-of-life is April 30, 2026. Azure’s standard support for these versions extends slightly beyond those dates (until March 31, 2026 for 5.7, and May 31, 2026 for 8.0). After those points, servers on 5.7 or 8.0 enter Extended Support, a paid support phase that provides critical fixes for up to three years (through 2029). Running your database in Extended Support means additional costs. Upgrading to MySQL 8.4 now ensures your database stays within standard support for years to come, sparing you the hassle of last-minute upgrades or extended support fees.

Benefits of MySQL 8.4: MySQL 8.4 is essentially an evolution of 8.0, so it brings numerous performance enhancements, security patches, and new SQL features that have been introduced since 8.0. Because it’s an LTS release, MySQL 8.4 is designed for stability – making it an ideal target for enterprises. Most applications that work on MySQL 8.0 will be compatible with 8.4 with little to no changes, but with 8.4 you gain improvements in areas like replication, query optimization, and JSON handling (among others) that can boost your application’s efficiency. Moreover, by standardizing on 8.4, you align with the version that will receive updates well into the future. In summary, upgrading means better reliability, availability, and security now, and assured support longevity.

Upgrading from MySQL 8.0 (In-Place Upgrade)

For current Azure Database for MySQL 8.0 users, moving to 8.4 is straightforward, thanks to our in-place major version upgrade capability. You can upgrade your existing 8.0 server to 8.4 on the same server instance, without dumping and restoring data. Here’s how it works:

• Upgrade Availability: If you create a new MySQL 8.0 server today (post-GA), the option to upgrade to 8.4 is available immediately in the Azure portal or CLI. For existing 8.0 servers (those created before this GA release), the upgrade capability will become available after your next scheduled maintenance window. The September 2025 platform update is enabling this feature across all regions. Note: Azure will not auto-upgrade your server during that maintenance; it only enables the new version as an option. You remain in control of when to perform the major version upgrade.
• Performing the Upgrade: Once the feature is enabled for your server, you can initiate the upgrade via the Azure portal, Azure CLI, or PowerShell. The process involves a downtime (the server will be taken offline and restarted on MySQL 8.4), so plan to execute during a maintenance window or low-traffic period. We strongly recommend taking a backup or snapshot before upgrading, as a precaution. For a step-by-step guide and best practices (including how to minimize downtime by using read replicas for the upgrade), refer to the official Azure documentation on https://learn.microsoft.com/azure/mysql/flexible-server/how-to-upgrade. In most cases, upgrading from 8.0 to 8.4 is completed within several minutes. After upgrade, your server retains the same endpoints, configuration, and data – just running on the new MySQL 8.4 engine.

Upgrading from MySQL 5.7 (Two-Step Path)

Upgrading from MySQL 5.7 to 8.4 requires a two-step approach, since a direct jump is not supported:

1. First upgrade 5.7 to 8.0: Azure MySQL Flexible Server supports in-place major upgrade from 5.7 to 8.0. This moves your server to a supported major version and is a necessary intermediate step (you cannot skip major versions in one go). MySQL 8.0 introduced some changes from 5.7 (for example, stricter SQL modes and a new default authentication plugin), so after upgrading to 8.0, test your application and fix any compatibility issues. Azure’s standard support for 5.7 runs until March 31, 2026, so you should aim to complete this step before then.
2. Then upgrade 8.0 to 8.4: With your server now on 8.0, you can use the in-place upgrade to 8.4 as described above. All Azure 8.0 servers will have the 8.4 upgrade option by the end of the next maintenance cycle (after the feature rollout in September 2025). Plan to perform the 8.0 → 8.4 upgrade at a convenient time, ideally well before MySQL 8.0’s support winds down in 2026. This final step ensures you’re on the latest GA version and out of the legacy support cycle.

Some customers may choose to migrate 5.7 to 8.4 by creating a new 8.4 server and importing data (using dump and restore or Azure Database Migration Service). This approach can be useful if you want to reorganize your environment or test in parallel. However, it will likely involve more downtime than the sequential in-place upgrades. Evaluate which method fits your needs – either way, now is the time to start, given that free support for 5.7 ends in less than two years.

Support Timeline Summary and Next Steps

To recap the support timelines and why upgrading matters:

• MySQL 5.7: Community EOL: Oct 31, 2023. Azure standard support until: March 31, 2026. After that, servers enter extended support (critical fixes only, with additional charges) until March 31, 2029. Action: Plan to upgrade off 5.7 before Q1 2026 to stay within standard support.
• MySQL 8.0: Community EOL: Apr 30, 2026. Azure standard support until: May 31, 2026. Extended support then runs to May 31, 2029. Action: Begin upgrading 8.0 instances to 8.4 in the coming months, rather than waiting until the last moment. The upgrade feature is available now (or after one maintenance cycle for older servers).
• MySQL 8.4: GA start: Sep 2025 (now). This is the recommended target for all MySQL deployments on Azure going forward. It will be fully supported on Azure well beyond 2026, receiving regular updates and improvements as part of the Azure service. Action: Deploy new databases on 8.4 and upgrade existing 5.7/8.0 databases to 8.4 when feasible, to benefit from the latest features and long-term support.

Next Steps: Getting started with MySQL 8.4 on Azure is easy. You can create a new Azure Database for MySQL 8.4 server from the Azure Portal or via CLI today. For existing servers, review the https://learn.microsoft.com/azure/mysql/flexible-server/how-to-upgrade to choose your upgrade method (in-place with some downtime vs. replica method for minimal downtime) and schedule a time for the upgrade.

By moving to Azure Database for MySQL 8.4, you’re investing in a more stable, performant, and future-proof foundation for your applications. We’re thrilled to see customers embrace MySQL 8.4, and we’re committed to making your upgrade process as smooth as possible. Upgrade with confidence, and leverage the power of MySQL 8.4 in Azure to drive your business forward!

For more information or to provide feedback, contact Ask Azure Database For MySQL.