Changes to the release process going forward

As AMP has grown, the number of users climbed to impressive levels, and the number of use cases being covered has spread out massively - the complexity of maintaining AMP has increased significantly.

What originally started over 10 years ago as a hobby project for a relatively small handful of enthusiasts is now the core software that businesses operate on and that large networks use to manage large numbers of players.

The earliest enthusiasts are of course a very tolerant bunch. Early adopters who don’t mind a few rough edges or some bugs if it means they get the latest features first - and that’s fine in the early days, but not sustainable in the long run.

Recently there have been a couple of issues surrounding updates that have caused issues as a result of insufficient test coverage, a lack of recovery options, or ‘heisenbugs’ that appear on some systems but not on others, that make testing difficult. Some of these are unavoidable, what matters is that users have better tools to avoid this from disrupting their workflow.

Changes we’re making immediately

Release Timing

Releases will now only happen on Wednesday afternoons at about 15:00 UK time, this will allow time for any ‘gotcha’ issues to be quickly addressed. This will also become the regular update window that server admins can plan around.

The sole exception to this will be emergency security updates, in which case regardless of what time - day or night - someone will be around for a few hours afterwards to oversee the process.

Use of CI and Nightly builds

CI (also known as Bleeding) and Nightly builds are going to disappear completely from public view. These will be replaced with “Development” builds which are those that may contain new features/fixes, but are not ready for general use at this time. The Fast Track release stream is also going to be removed as it is not being used.

The end of Stealth Updates

Some AMP updates have been shipped as what have been informally known as ‘Stealth’ updates. These updates didn’t come with a version number change, and is why it was necessary to use the --nocache parameter to get the updated version. These were usually used when a fix was pushed very quickly after a release.

Changes Coming Soon

Patch Version Updates

To accomodate the end of stealth updates, the change that will come along with this in the near future is that build versions will include their timestamp. So now there may be and - same basic version, but with a rebuild issued for whatever reason. The latter part will be shown as the ‘patch’ version.

Update rollbacks

Standard AMP Users (those on Pro) will have the ability to roll back to their previous version after an update. A backup of AMPs core components (executables, core configuration files) will be kept for a short time after updating. If there is some problem that was unanticipated, you will be able to roll AMPs core components right back to their previous state easily - but only back by a single version or update.

Current version deployments

One of the features currently in Enterprise only will be made available to all AMP users. Enterprise has the ability to create new instances whose version match that of ADS. This means you don’t have the situation where you can’t manage a new instance because it’s a newer version than ADS and forcing you to upgrade everything. This will be made available to everyone regardless of edition soon, this way you can upgrade at your leisure rather than being forced to when you want to deploy a new game server.

Version Selections

Advanced users of AMP (Those on Network, Enterprise, etc) will have an even more in-depth ability to pick exactly which AMP version they want to deploy for new instances to. The plan is to maintain approximately 3 months of back versions (unless security issues dictate that older versions be removed).

‘Live’ updates for certain components

Certain types of updates that don’t involve backend or API changes will be able to be applied without stopping your running game server, or even having to restart AMP itself.

In Closing

I’d like to thank all of our users for our patience during what has been a challenging period of transformation. CubeCoders has massively size of its user base over the last few years - far beyond what anyone expected. AMPs ease of use, simple installation and powerful plugin system have made it a force to be contended with.

I’d also like to give personal thanks to a few particular users:

  • Greelan
  • IceOfWraith
  • Arc
  • onepineapple
  • Shinynecrid
  • Sneakysnek

These 6 members probably account for 90% of the conversations I have on Discord, trying to navigate what direction AMP should be going to them - and the entire community owes them a debt of gratitude for their time, patience, and occasional kick up my backside when things aren’t going the way they should.

These issues aside, we do have some very exciting changes in the pipeline that we look forward to sharing with all of you once it’s appropriate and we’ve got some of the more pressing issues out of the way :slight_smile:

One Final Note

Turning on the usage collection options (Configuration → Privacy → Auto-report errors, and Allow Analytics) provides me with really useful information that helps to identify problems early.

The data is completely anonymous, isn’t tracked, and all data is 100% hosted by CubeCoders on servers we control. It tells us which applications people are using, when updates are installed, and a few other details (that we’ll document in a little more detail soon) - but really helps identify how AMP is being used and where pain points might exist.