[email protected]

## [2.0.0-preview.6] - 2019-3-29
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.
* Update package target Unity version to Unity 2019.1.

## [2.0.0-preview.4] - 2019-2-5
* Fix an issue with with an NRE in the build processor.

.github/CODEOWNERS

@@ -0,0 +1,4 @@
+# Required reviewers
+
+* @joejo @lukaszp
+

CHANGELOG.md

@@ -4,6 +4,20 @@ 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.6] - 2019-3-29
+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.
+* Update package target Unity version to Unity 2019.1.
+
+## [2.0.0-preview.4] - 2019-2-5
+* Fix an issue with with an NRE in the build processor.
+
+## [2.0.0-preview.3] - 2019-1-22
+* Add missing repo url to package json file
+* Fix NRE issue in build processor
+
 ## [2.0.0-preview.3] - 2019-1-22
 * Fix error in general build processor due to a potential null deref.
 * Fix missing check for unity version when referencing UIElements.

Documentation~/EndUser.md

@@ -0,0 +1,43 @@
+# End Users
+
+## Add default loader and settings instances if requested
+
+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.
+
+## 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.
+* 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.
+
+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 **XRManager.activeLoader** field once XR SDK has been initialized.
+
+## Customize build and runtime settings
+
+Any package that needs build or runtime settings should provide a settings datatype for use. This will be surfaced in the **Unified Settings** UI window underneath a top level **XR** node. By default a custom settings data instance will not be created. If you wish to modify build or runtime settings for the package you must go to the package authors entry in **Unified Settings** and select **Create**. This will create an instance of the settings that you can then modify inside of **Unified Settings**.
+
+# Installing *XR SDK Management*
+
+Most likey the XR SDK Provider package you want to use already includes XR Management so you shouldn't need to install it. If you do you can follow the directions provided in the top level documentation or follow the instructions in the [Package Manager documentation](https://docs.unity3d.com/Packages/com.unity.package-manager-ui@latest/index.html).
+
+
+## Document revision history
+
+|Date|Reason|
+|---|---|
+|March 8, 2019|Create document.|

Documentation~/Provider.md

@@ -0,0 +1,121 @@
+# Package Author
+
+## 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.
+
+A provider must create a subclass of **XRLoader** to make a loader available for their particular runtime scheme.
+
+The **XRLoader** interface looks like this:
+
+```csharp
+public abstract class XRLoader : ScriptableObject
+{
+    public virtual bool Initialize() { return false; }
+
+    public virtual bool Start() { return false; }
+
+    public virtual bool Stop() { return false; }
+
+    public virtual bool Deinitialize() { return false; }
+
+    public abstract T GetLoadedSubsystem<T>() where T : IntegratedSubsystem;
+}
+```
+
+There is a class called **XRLoaderHelper** which you can derive from to handle subsystem management in a typesafe manner.  See **[Samples/SampleLoader.cs](/Samples/SampleLoader.cs)** for an example.
+
+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.
+
+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.
+
+Scene based Automatic lifecycle management hooks into the following **MonoBehaviour** callback points:
+
+|Callback|Lifecycle Step|
+|---|---|
+|OnEnable|Find the first loader that succeeds initialization and set ActiveLoader.|
+|Start|Start all subsystems|
+|OnDisable|Stop all subsystems|
+|OnDestroy|De-initialize all subsystems and remove the ActiveLoader instance.|
+
+App lifetime based Automatic lifecycle management hooks into the following callback points:
+
+|Callback|Lifecycle Step|
+|---|---|
+|Runtime Initialization After Assemblies Loaded|Find the first loader that succeeds intiialization and set ActiveLoader.|
+|Runtime Initialization Before splash screen is shown|Start all subsystems|
+|OnDisable|Stop all subsystems|
+|OnDestroy|Deintialize all subsystems and remove the ActiveLoader instance.|
+
+## Build and Runtime settings through *Unified Settings*
+
+A provider may need optional settings to help manage build issues or runtime configuration. They can do this by adding the **XRConfigurationData** attribute to a ScriptableObject and providing the set of properties they want to surface for users to control configuration. Configuration options will be surfaced in the **Unified Settings** window under the **XR** top level entry. We will manage the lifecycle for one instance of the class marked with the attribute through the EditorBuildSettings config object API. If no special UI is provided, the **Unified Settings** window will display the configuration settings using the standard **ScriptableObject** UI Inspector. A provider can extend the UI by creating a custom **Editor** for their configuration settings type and that will be used in the **Unified Settings** window instead. 
+
+The provider will need to handle getting the settings from **EditorUserBuildSettings** into the build application. This can be done with a custom build processing script. If all you need for build support is to make sure that you have access to the same settings at runtime you can derive from **XRBuildHelper<T>**. This is a generic abstract base class that handles the necessary work of getting the build settings stored in EditorUserBuildSettings and getting them into the build application for access at runtime. Simplest build script for your package would look like this:
+
+```csharp
+public class MyBuildProcessor : XRBuildHelper<MySettings> 
+{
+    public override string BuildSettingsKey { get { return "MyPackageSettingsKey"; } }
+}
+```
+
+You can override the build processing steps from **IPreprocessBuildWithReport** and **IPostprocessBuildWithReport** but make sure that you call to the base class implementation or else your settings will not be copied.
+
+```csharp
+public class MyBuildProcessor : XRBuildHelper<MySettings> 
+{ 
+    public override string BuildSettingsKey { get { return "MyPackageSettingsKey"; } }
+
+    public override void OnPreprocessBuild(BuildReport report)
+    {
+        base.OnPreprocessBuild(report);
+        // Do your work here
+    }
+
+    public override void OnPostprocessBuild(BuildReport report)
+    {
+        base.OnPreprocessBuild(report);
+        // Do your work here
+    }
+}
+```
+
+If you wish to support per platform settings at build time, you can override `UnityEngine.Object SettingsForBuildTargetGroup(BuildTargetGroup buildTargetGroup)` and use the passed in buildTargetGroup to retrieve the appropriate platform settings. By default this method just uses the key associated with the settings instance to copy the entire settings object from EditorUserBuildSettings to PlayerSettings.
+
+```csharp
+public class MyBuildProcessor : XRBuildHelper<MySettings> 
+{ 
+    public override string BuildSettingsKey { get { return "MyPackageSettingsKey"; } }
+
+    public override UnityEngine.Object SettingsForBuildTargetGroup(BuildTargetGroup buildTargetGroup)
+    {
+        // ... Get platform specific settings and return them... Something like the following
+        // for simple settings data that isn't platform specific.
+        UnityEngine.Object settingsObj = null;
+        EditorBuildSettings.TryGetConfigObject(BuildSettingsKey, out settingsObj);
+        if (settingsObj == null || !(settingsObj is T))
+            return null;
+
+        return settingsObj;
+
+    }
+}
+```
+
+If you need more extensive support and/or absolute control you can copy the **SampleBuildProcessor** in the _Samples/Editor_ folder and work from there.
+
+## 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.
+
+# Installing *XR SDK Management*
+
+To install this package, follow the instructions in the [Package Manager documentation](https://docs.unity3d.com/Packages/com.unity.package-manager-ui@latest/index.html).
+
+
+|Date|Reason|
+|---|---|
+|March 8, 2019|Create document.|