Merge pull request #8109 from open-sausages/pulls/3/docs-3.7.0-guide

Object upgrade notice for 3.7.0 changelog

docs/en/04_Changelogs/3.7.0.md

@@ -1,6 +1,48 @@
-# 3.7.0
+# 3.7.0 (unreleased)
 
-### Versioned cache segmentation
+## SilverStripe 3.7 and PHP 7.2 and Object subclasses
+
+### For Project Code
+
+SilverStripe 3.7 now supports PHP 7.2, which is exciting, but PHP 7.2 introduces an `object` keyword.
+To use it, you can replace any uses of `Object` with `SS_Object` in your own project code.
+
+```diff
+-class MyClass extends Object
++class MyClass extends SS_Object
+{
+	public function myFunction()
+	{
+-		$foo = Object::has_extension('MyExtension');
++		$foo = SS_Object::has_extension('MyExtension');
+	}
+}
+```
+
+You are also reliant on any SilverStripe modules directly using `Object` to upgrade their codebase.
+Matches for `SS_Object` in the module codebase will tell you it's been upgraded.
+A search for `extends Object` or `Object::` isn't fool proof, but will give you an indication
+that the module still needs to be upgraded. If in doubt, check the module README.
+
+### For Module Authors
+
+If you are publishing a 3.x-compatible module that directly references the `Object` class,
+we recommend that you replace all references to `Object` with `SS_Object`,
+and add the following line to your module's `_config.php`
+in order to support both current SilverStripe 3.x and SilverStripe 3.7 releases running on PHP 7.2:
+
+```php
+// Ensure compatibility with PHP 7.2 ("object" is a reserved word),
+// with SilverStripe 3.6 (using Object) and SilverStripe 3.7 (using SS_Object)
+if (!class_exists('SS_Object')) class_alias('Object', 'SS_Object');
+```
+
+Don't forget to mention explicit PHP 7.2 and SilverStripe 3.7 compatibility in your module README.
+
+Note that in SilverStripe 4.x, the `Object` class was deleted so there isn’t an `SS_Object` class there either
+(see [https://docs.silverstripe.org/en/4/changelogs/4.0.0/](changelog))
+
+## Versioned cache segmentation
 
 `SS_Cache` now maintains separate cache pools for each versioned stage. This prevents developers from caching draft data and then accidentally exposing it on the live stage without potentially required authorisation checks. Unless you rely on caching across stages, you don't need to change your own code for this change to take effect. Note that cache keys will be internally rewritten, causing any existing cache items to become invalid when this change is deployed.
 
@@ -24,3 +66,4 @@ Data that is not content sensitive can be cached across stages by simply opting
 ```php
 $cache = SS_Cache::factory('myapp', 'Output', array('disable-segmentation' => true));
 ``` 
+