[email protected]

## [2.0.0-preview.9] - 2019-4-10
* Fix package validation console errors.

## [2.0.0-preview.8] - 2019-4-10
* Fix package validation compilation errors.
* Remove .github folder from npm packaging.

## [2.0.0-preview.7] - 2019-4-10
* Streamlining of the management system. Move XR Manager to a singleton instance on XRGeneralSettings that is populated by an XRManagerSettings instance that the user can switch in and out. __NOTE: This removes the ability to use XRManagement for per scene situations. For hybrid or manual scenes the user will be responsible for instantiating/loading the XRManagerSettings instance they want and dealing with lifecycle themselves.__

CHANGELOG.md

@@ -4,8 +4,18 @@ All notable changes to this package will be documented in this file.
 The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
 and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).
 
+## [2.0.0-preview.9] - 2019-4-10
+* Fix package validation console errors.
+
+## [2.0.0-preview.8] - 2019-4-10
+* Fix package validation compilation errors.
+* Remove .github folder from npm packaging.
+
+## [2.0.0-preview.7] - 2019-4-10
+* Streamlining of the management system. Move XR Manager to a singleton instance on XRGeneralSettings that is populated by an XRManagerSettings instance that the user can switch in and out. __NOTE: This removes the ability to use XRManagement for per scene situations. For hybrid or manual scenes the user will be responsible for instantiating/loading the XRManagerSettings instance they want and dealing with lifecycle themselves.__
+
 ## [2.0.0-preview.6] - 2019-3-29
-Fix up package repo information for rel mgmt.
+* Fix up package repo information for rel mgmt.
 
 ## [2.0.0-preview.5] - 2019-2-5
 * Split documentation into separate audience files for End Users and Providers.

Documentation~/EndUser.md

@@ -4,28 +4,17 @@
 
 At package install time, the package may prompt you to create an instance of a loader and an instance of settings for the package. This step is entirely optional and is there simply to help the user get things going at installation time.
 
-If you wish not to create this at installation time, the appropriate portion of the editor that require them (**XRManager** and **Unified Settings** will) prompt you to create them as well.
+If you wish not to create this at installation time, the appropriate portion of the editor that require them (**XRManagerSettingsSettings** and **Unified Settings** will) prompt you to create them as well.
 
-## Add an **XRManager** instance to your scene
-
-### If you wish to start XR SDK on a per scene basis (i.e. start in 2D and transition into VR)
-* Create a new empty Game Object in your scene.
-* Add an instance of the **XRManager** component to this new Game Object.
-* Use the **XRManager** component Inspector UI to add/create, remove and reorder the loaders you wish to use.
-
-When the scene loads, XR Manager will attempt to create and start the set of subsystems for the first loader that successfully initializes. Unless otherwise specified, XR Manager will manage the lifetime of the XR SDK session within the life time of the scene.
-
-### If you wish to start XR SDK at launch and keep it running throughout the app lifetime.
-* Open and scene and create an empty **Game Object**. Add an **XR Manager** component to that **Game Object**. 
-* Drag the **Game Object** to the Project heirarchy and create a prefab from that instance. Delete the **Game Object** instance from the scene.
-* Open the prefab in the Prefab Editor and go to the inspector for the prefab.
-* Populate the **XR Manager** instance with the set of loaders you wish to use for your application.
+### Set up XR SDK settings with loaders you want to run.
 * Navigate to **Unified Settings**.
-* Select the top level **XR** node. Drag the prefab to the XR Manager Instance and drop it. This prefab is now assigned to the global XR settings system and will be used to manage the lifetime of the XR SDK for the lifetime of the application.
+* Select the top level **XR** node.
+* Modify loaders
 
-The instance of the **Game Object** that contains the **XR Manager** component instance you wish to use can be set/accessed using **XRGeneralSettings.Instance.m_LoaderManagerInstance**. This allows you to change the prefab instance that you want to use at build time so that you can change loader configuration depending on build target.
+**NOTE**: You can always manually control the XR SDK system by accessing the **XRManagerSettingsSettings.activeLoader** field once XR SDK has been initialized.
 
-**NOTE**: You can always manually control the XR SDK system by accessing the **XRManager.activeLoader** field once XR SDK has been initialized.
+### If you wish to start XR SDK on a per scene basis (i.e. start in 2D and transition into VR)
+* Use the **XRGeneralSettings.Instance.m_LoaderManagerInstance** to add/create, remove and reorder the loaders you wish to use from the script.
 
 ## Customize build and runtime settings
 

Documentation~/Provider.md

@@ -2,7 +2,7 @@
 
 ## Lifecycle Management
 
-This package provides for management of **XR SDK** subsystem lifecycle without the need for boilerplate code. The **XRManager** class provides a component that can be added to a game object in the scene that will manage initialization, start, stop and de-initialization of a set of subsystems defined by an **XRLoader** instance. The **XRManager** instance can handle all of the lifecycle management, init/de-init only, subsystem start/stop only or can leave all of it up to the user.
+This package provides for management of **XR SDK** subsystem lifecycle without the need for boilerplate code. The **XRManagerSettings** class provides a scriptable object that can be used by the app for start, stop and de-initialization of a set of subsystems defined by an **XRLoader** instance.
 
 A provider must create a subclass of **XRLoader** to make a loader available for their particular runtime scheme.
 
@@ -27,9 +27,9 @@ There is a class called **XRLoaderHelper** which you can derive from to handle s
 
 An **XRLoader** is simply a **ScriptableObject** and as such, the user is able to create and instance (or more if they want) of the loader. Each **XRLoader** subclass defines the subsystems and their load order and is responsible for managing the set of subsystems they require.
 
-A user will add all the **XRLoaders** instances they created to the Loaders property on the **XRManager**, arranging them in the load order that they desire.
+A user will add all the **XRLoaders** instances they created to the Loaders property on the **XRManagerSettings**, arranging them in the load order that they desire.
 
-When asked to initialize, **XRManager** will call each **XRLoader** instance it has a reference to in the order it has and attempt to initialize each one. The first loader that succeeds initialization becomes the active loader and all further attempts to initialize are stopped. From this point the user can ask for the static **XRManager.ActiveLoader** instance to get access to the active loader. If initialization fails for all loaders, **ActiveLoader** is set to null.
+When asked to initialize, **XRManagerSettings** will call each **XRLoader** instance it has a reference to in the order it has and attempt to initialize each one. The first loader that succeeds initialization becomes the active loader and all further attempts to initialize are stopped. From this point the user can ask for the static **XRManagerSettings.ActiveLoader** instance to get access to the active loader. If initialization fails for all loaders, **ActiveLoader** is set to null.
 
 Scene based Automatic lifecycle management hooks into the following **MonoBehaviour** callback points:
 
@@ -109,7 +109,7 @@ If you need more extensive support and/or absolute control you can copy the **Sa
 
 ## Package Initialization
 
-Given the need for **ScriptableObject** instance to support loaders and settings, the user will be forced to create these instances at some point. Both **XRManager** and the **Unified Settings** support can handle creating the necessary instances on demand but it may be beneficial to create these up front at package installation. If you derive a class from **XRPackageInitializationBase** and fill out the interface properties and methods the management system will provide for creation of default instances of your loader and settings at installation. Creation of each one is driven by prompting the user if it is OK to do that and, if so, creating the instance in the appropriate default location in the Assets folder. For loaders this is Assets/XR/Loaders. For settings this is Assets/XR/Settings. While these are the recommended locations for putting these package based objects they do not have to be located there. The user is free to move them around as long as we can find at least one instance of each type for each package.
+Given the need for **ScriptableObject** instance to support loaders and settings, the user will be forced to create these instances at some point. Both **XRManagerSettings** and the **Unified Settings** support can handle creating the necessary instances on demand but it may be beneficial to create these up front at package installation. If you derive a class from **XRPackageInitializationBase** and fill out the interface properties and methods the management system will provide for creation of default instances of your loader and settings at installation. Creation of each one is driven by prompting the user if it is OK to do that and, if so, creating the instance in the appropriate default location in the Assets folder. For loaders this is Assets/XR/Loaders. For settings this is Assets/XR/Settings. While these are the recommended locations for putting these package based objects they do not have to be located there. The user is free to move them around as long as we can find at least one instance of each type for each package.
 
 # Installing *XR SDK Management*
 

Documentation~/com.unity.xr.management.md

@@ -66,8 +66,8 @@ This version of **XR SDK Management** is compatible with the following versions
 
 This version of **XR SDK Management** includes:
 
-* **XRManager** - This is a **MonoBehaviour** that can be added to a **GameObject** in a scene and provides for management of **XRLoader** instances and their lifecycle.
-* **XRLoader** - This is the base class all loaders should derive from. It provides a basic the **XRManager** can use to manage lifecycle and a simple API to allow users to request specific subsystems from the loader as and when needed.
+* **XRManagerSettingsSettingsSettings** - This is a **ScriptableBehaviour** that can be accessed from the script and provides for management of **XRLoader** instances and their lifecycle.
+* **XRLoader** - This is the base class all loaders should derive from. It provides a basic the **XRManagerSettingsSettingsSettings** can use to manage lifecycle and a simple API to allow users to request specific subsystems from the loader as and when needed.
 * **XRConfigurationData** - This is an attribute that allows for build and runtime settings to be hosted within the **Unified Settings** window. All instances will be hosted under the top level **XR** entry within the **Unified Settings** window under the name supplied as part of the attribute. The management package will maintain and manage the lifecycle for one instance of the build settings using **EditorBuildSettings** config object API, stored with the key provided in the attribute. At any time, the provider or the user is free access the configuration settings instance by asking **EditorBuildSettings** for the instance associated with the chosen key (as set in the attribute).
 * **XRPackageInitializationBase** - Helper class to derive from that simplifies some of the busy work for package initialization. Helps to create a default instance of the packages XRLoader and default settings at the time of package installation. Initialization is run once only and the package developer should not depend on the user creating the specified instances.
 * **XRBuildHelper** - Abstract class useful for handling some boilerplate around moving settings from Editor -> Runtime. Derive from this class and specific the appropriate settings type and the system will take care of marshaling that type from EditorUserBuildSettings to PlayerSettings to be used at runtime.