There’s changes afoot!
Changes we’re making on the path to AMP 2.6 and onwards to 3.0.
AMP is coming up to 10 years old now, having first been announced at the tail end of 2014 and officially released in 2015. Back then AMP supported just 5 individual games plus the Source module for another dozen or so more. A far cry from the over 150 games and applications that AMP supports today.
And while AMP has undergone some significant changes in that time, it has fundamentally remained on essentially the same frameworks and tooling for most if this time with only incremental updates. Components have been replaced and upgraded during this time, but now the tools and frameworks AMP currently depends on are starting to show their age and hold back development.
Give me the short version, what do I need to know?
AMP is getting a major update to its core and underlying frameworks to keep its tooling modern and make it easier to keep updating into the future. This isn’t something that will affect normal users much aside from a couple of big updates that everyone gets put on yet contain no new features.
The recently released AMP 2.5.1.8 update was in fact the final release based on the old framework and tooling. All updates going forward will be using a new framework and toolset.
So, what’s the actual plan here?
Step 1: Don’t break anything!
Right now, we’re in the middle of a significant modernisation project within AMPs core to upgrade it to the absolute latest frameworks and tooling, and removing a lot of cruft and legacy dependencies in the process. The final result will be a leaner, cleaner, faster and much easier to maintain application.
To start with the goal is simple feature parity. To get everything migrated without losing or breaking any functionality. This will form the basis of AMP 2.6, which from a functional perspective will be a ‘non-upgrade’ because it’s not expected to contain any new features or user-facing changes. It’s job is to make sure that nothing is lost in the process of the upgrades.
Step 2: Remove the cruft
Once we’ve achieved functional parity, the next goal is to remove some of the legacy components that have modern replacements. One of the issues that has really held back some of AMPs functionality has been the use of its in-process webserver library called mHttp - which until recently had a series of bugs which severely affected its performance. It was great when we first started using it, but it’s lack of support for file streaming, HTTP3 and other modern technologies is a hindrance.
Step 3: Maintainence
At this point, bugs or features that were held back because of these legacy components can be addressed. This along with the usual set of steady feature additions and improvements will form the basis of the rest of the 2.x series of updates.
Step 4: ??? ???
AMP 3.0 is something we’re starting to give some thought to, there are certain goals we would really like to meet in order to really improve AMPs experience, including for example the ability to update AMP without having to shut down the game servers it’s taking care of somehow. Whether this is a rewrite of the core or a modification to 2.x remains to be seen.