fzhangtj
6 年前
当前提交
a1b34c06
共有 87 个文件被更改,包括 1866 次插入 和 1 次删除
-
407README.md
-
242.README - External.md
-
18.gitlab-ci.yml
-
19.npmignore
-
8Assets.meta
-
8Assets/Plugins.meta
-
11CHANGELOG.md
-
7CHANGELOG.md.meta
-
9CONTRIBUTING.md
-
7CONTRIBUTING.md.meta
-
8Editor.meta
-
5LICENSE.md
-
7LICENSE.md.meta
-
8Packages.meta
-
7Packages/manifest.json.meta
-
8ProjectSettings.meta
-
8ProjectSettings/AudioManager.asset.meta
-
8ProjectSettings/ClusterInputManager.asset.meta
-
8ProjectSettings/DynamicsManager.asset.meta
-
8ProjectSettings/EditorBuildSettings.asset.meta
-
8ProjectSettings/EditorSettings.asset.meta
-
8ProjectSettings/GraphicsSettings.asset.meta
-
8ProjectSettings/InputManager.asset.meta
-
8ProjectSettings/NavMeshAreas.asset.meta
-
8ProjectSettings/NetworkManager.asset.meta
-
8ProjectSettings/Physics2DSettings.asset.meta
-
8ProjectSettings/PresetManager.asset.meta
-
8ProjectSettings/ProjectSettings.asset.meta
-
7ProjectSettings/ProjectVersion.txt.meta
-
8ProjectSettings/QualitySettings.asset.meta
-
8ProjectSettings/TagManager.asset.meta
-
8ProjectSettings/TimeManager.asset.meta
-
8ProjectSettings/UnityConnectSettings.asset.meta
-
26QAReport.md
-
7QAReport.md.meta
-
7README.md.meta
-
8Runtime.meta
-
8Samples.meta
-
8Tests.meta
-
16Third Party Notices.md
-
7Third Party Notices.md.meta
-
19build.bat
-
7build.bat.meta
-
16build.sh
-
7build.sh.meta
-
9package.json
-
7package.json.meta
-
8scripts.meta
-
8scripts/cmds.meta
-
11scripts/cmds/codegen.js.meta
-
7scripts/gitignore.meta
-
7scripts/package.json.meta
-
11scripts/uiwidgets-cli.js.meta
-
315Documentation~/images/example.png
-
169Documentation~/your-package-name.md
-
30Editor/EditorExample.cs
-
11Editor/EditorExample.cs.meta
-
10Editor/Unity.UIWidgets.Editor.asmdef
-
7Editor/Unity.UIWidgets.Editor.asmdef.meta
-
30Runtime/RuntimeExample.cs
-
11Runtime/RuntimeExample.cs.meta
-
6Runtime/Unity.UIWidgets.asmdef
-
7Runtime/Unity.UIWidgets.asmdef.meta
-
8Samples/Example.meta
-
5Samples/Example/.sample.json
-
6Samples/Example/SampleExample.cs
-
11Samples/Example/SampleExample.cs.meta
-
3Tests/.tests.json
-
8Tests/Editor.meta
-
22Tests/Editor/EditorExampleTest.cs
-
11Tests/Editor/EditorExampleTest.cs.meta
-
14Tests/Editor/Unity.UIWidgets.EditorTests.asmdef
-
7Tests/Editor/Unity.UIWidgets.EditorTests.asmdef.meta
-
8Tests/Runtime.meta
-
21Tests/Runtime/RuntimeExampleTest.cs
-
11Tests/Runtime/RuntimeExampleTest.cs.meta
-
11Tests/Runtime/Unity.UIWidgets.Tests.asmdef
-
7Tests/Runtime/Unity.UIWidgets.Tests.asmdef.meta
|
|||
# UIWidgets |
|||
# UPM Package Starter Kit |
|||
|
|||
The purpose of this package template starter kit is to provide the data structure and development guidelines for new packages meant for the **Unity Package Manager (UPM)**. |
|||
|
|||
This is the first of many steps towards an automated package publishing experience within Unity. This package template starter kit is merely a fraction of the creation, edition, validation, and publishing tools that we will end up with. |
|||
|
|||
We hope you enjoy your experience. You can use **#devs-packman** on Slack to provide feedback or ask questions regarding your package development efforts. |
|||
|
|||
## Are you ready to become a package? |
|||
The Package Manager is a work-in-progress for Unity and, in that sense, there are a few criteria that must be met for your package to be considered on the package list at this time: |
|||
- **Your code accesses public Unity C# APIs only.** If you have a native code component, it will need to ship with an official editor release. Internal API access might eventually be possible for Unity made packages, but not at this time. |
|||
- **Your code doesn't require security, obfuscation, or conditional access control.** Anyone should be able to download your package and access the source code. |
|||
- **You have no urgent need to release your package.** Our current target for new packages is aligned with 2018.1. Although, based on upcoming package requests and limited packman capacity, that release date is not assured for any package. |
|||
- **You are willing to bleed with us a little!** Packman is still in development, and therefore has a few rough edges that will require patience and workarounds. |
|||
|
|||
## Package structure |
|||
|
|||
```none |
|||
<root> |
|||
├── package.json |
|||
├── README.md |
|||
├── CHANGELOG.md |
|||
├── LICENSE.md |
|||
├── Third Party Notices.md |
|||
├── QAReport.md |
|||
├── Editor |
|||
│ ├── Unity.[YourPackageName].Editor.asmdef |
|||
│ └── EditorExample.cs |
|||
├── Runtime |
|||
│ ├── Unity.[YourPackageName].asmdef |
|||
│ └── RuntimeExample.cs |
|||
├── Tests |
|||
│ ├── .tests.json |
|||
│ ├── Editor |
|||
│ │ ├── Unity.[YourPackageName].Editor.Tests.asmdef |
|||
│ │ └── EditorExampleTest.cs |
|||
│ └── Runtime |
|||
│ ├── Unity.[YourPackageName].Tests.asmdef |
|||
│ └── RuntimeExampleTest.cs |
|||
├── Samples |
|||
│ └── Example |
|||
│ ├── .sample.json |
|||
│ └── SampleExample.cs |
|||
└── Documentation~ |
|||
├── your-package-name.md |
|||
└── Images |
|||
``` |
|||
|
|||
## Develop your package |
|||
Package development works best within the Unity Editor. Here's how to set that up: |
|||
|
|||
1. Clone the `package-template` repository locally |
|||
|
|||
- In a console (or terminal) application, choose a place to clone the repository and perform the following : |
|||
``` |
|||
git clone https://gitlab.cds.internal.unity3d.com/upm-packages/upm-package-template.git |
|||
``` |
|||
|
|||
1. Create a new repository for your package and clone to you desktop |
|||
|
|||
- On Gitlab, navigate to the [upm-packages](https://gitlab.cds.internal.unity3d.com/upm-packages), and make sure you have a sub-group for your feature area. If you don't have one, you can request a new sub-group in #devs-packman. |
|||
- Create a new repository with the name of your package (Example: `"com.unity.terrain-builder"`) |
|||
- In a console (or terminal) application, choose a place to clone the repository and perform the following : |
|||
``` |
|||
git clone https://gitlab.cds.internal.unity3d.com/upm-packages/[your-sub-group]/com.unity.[sub-group].[your-package-name] |
|||
``` |
|||
|
|||
1. Start **Unity**, create a local empty project. |
|||
|
|||
1. In a console (or terminal) application, go to the newly created project folder, then clone your newly created package repository into the packages directory. |
|||
```none |
|||
cd <YourProjectPath>/Packages |
|||
git clone https://gitlab.internal.unity3d.com/upm-packages/[sub-group]/[your-package-name].git com.unity.[sub-group].[your-package-name] |
|||
``` |
|||
__Note:__ Your directory name must be the name of your package (Example: `"com.unity.terrain-builder"`) |
|||
|
|||
1. Copy the locally cloned upm-package-template folder contents to your locally cloned package's folder. Be careful not to copy the upm-package-template `.git` folder over. |
|||
|
|||
1. In a console (or terminal) application, push the template files you copied in your new package repository to it's remote |
|||
- Add them to your repository's list to version |
|||
```git add .``` |
|||
- Commit to your new package's remote master |
|||
```git commit``` |
|||
- Push to your new package's remote master |
|||
```git push``` |
|||
|
|||
1. ##### Fill in your package information |
|||
|
|||
Update the following required fields in file **package.json**: |
|||
- `"name"`: Package name, it should follow this naming convention: `"com.unity.[sub-group].[your-package-name]"` |
|||
(Example: `"com.unity.2d.animation"`, where `sub-group` should match the sub-group you selected in Gitlab) |
|||
- `"displayName"`: Package user friendly display name. (Example: `"Terrain Builder SDK"`). <br>__Note:__ Use a display name that will help users understand what your package is intended for. |
|||
- `"version"`: Package version `"X.Y.Z"`, your project **must** adhere to [Semantic Versioning](http://semver.org/spec/v2.0.0.html). |
|||
Follow this guideline: |
|||
- To introduce a new feature or bug fix, increment the minor version (X.**Y**.Z) |
|||
- To introduce a breaking API change, increment the major version (**X**.Y.Z) |
|||
- The patch version (X.Y.**Z**), is reserved for sustainable engineering use only. |
|||
- `"unity"`: Unity Version your package is compatible with. (Example: `"2018.1"`) |
|||
- `"description"`: This description appears in the Package Manager window when the user selects this package from the list. For best results, use this text to summarize what the package does and how it can benefit the user.<br>__Note:__ Special formatting characters are supported, including line breaks (`\n`) and unicode characters such as bullets (`\u25AA`).<br>For more information, see the [Writing Package docs](https://confluence.hq.unity3d.com/display/DOCS/Writing+Package+docs) page on Confluence. |
|||
|
|||
Update the following recommended fields in file **package.json**: |
|||
- `"dependencies"`: List of packages this package depends on. All dependencies will also be downloaded and loaded in a project with your package. Here's an example: |
|||
``` |
|||
dependencies: { |
|||
"com.unity.ads": "1.0.0" |
|||
"com.unity.analytics": "2.0.0" |
|||
} |
|||
``` |
|||
- `"keywords"`: List of words that will be indexed by the package manager search engine to facilitate discovery. |
|||
|
|||
Update the following field in file **Tests/.tests.json**: |
|||
- `"createSeparatePackage"`: If this is set to true, the CI will create an separate package for these tests. |
|||
|
|||
1. Restart Unity. For more information on embedded packages see [here](https://confluence.hq.unity3d.com/display/PAK/How+to+embed+a+package+in+your+project). |
|||
|
|||
1. If on 2018.1 - Enable package support in the editor (*Internal Feature*). From the **Project** window's right hang menu, enable `DEVELOPER`->`Show Packages in Project Window` (*only available in developer builds*). You should now see your package in the Project Window, along with all other available packages for your project. |
|||
|
|||
1. ##### Update **README.md** |
|||
|
|||
The README.md file should contain all pertinent information for developers using your package, such as: |
|||
* Prerequistes |
|||
* External tools or development libraries |
|||
* Required installed Software |
|||
* Command line examples to build, test, and run your package. |
|||
|
|||
1. ##### Rename and update **your-package-name.md** documentation file. |
|||
|
|||
Use this template to create preliminary, high-level documentation. This document is meant to introduce users to the features and sample files included in your package. |
|||
|
|||
1. ##### Rename and update assembly definition files. |
|||
|
|||
If your package contains Editor code, rename and modify [Editor/Unity.YourPackageName.Editor.asmdef](Editor/Unity.YourPackageName.Editor.asmdef). Otherwise, delete the Editor directory. |
|||
* Name **must** match your package name, suffixed by `.Editor` (i.e `Unity.[YourPackageName].Editor`) |
|||
* Assembly **must** reference `Unity.[YourPackageName]` (if you have any Runtime) |
|||
* Platforms **must** include `"Editor"` |
|||
|
|||
|
|||
If your package contains code that needs to be included in Unity runtime builds, rename and modify [Runtime/Unity.YourPackageName.asmdef](Runtime/Unity.YourPackageName.asmdef). Otherwise, delete the Runtime directory. |
|||
* Name **must** match your package name (i.e `Unity.[YourPackageName]`) |
|||
|
|||
If your package has Editor code, you **must** have Editor Tests. In that case, rename and modify [Tests/Editor/Unity.YourPackageName.Editor.Tests.asmdef](Tests/Editor/Unity.YourPackageName.Editor.Tests.asmdef). |
|||
* Name **must** match your package name, suffixed by `.Editor.Tests` (i.e `Unity.[YourPackageName].Editor.Tests`) |
|||
* Assembly **must** reference `Unity.[YourPackageName].Editor` and `Unity.[YourPackageName]` (if you have any Runtime) |
|||
* Platforms **must** include `"Editor"` |
|||
* Optional Unity references **must** include `"TestAssemblies"` to allow your Editor Tests to show up in the Test Runner/run on Katana when your package is listed in project manifest `testables` |
|||
|
|||
If your package has Runtime code, you **must** have Playmode Tests. In that case, rename and modify [Tests/Runtime/Unity.YourPackageName.Tests.asmdef](Tests/Runtime/Unity.YourPackageName.Tests.asmdef). |
|||
* Name **must** match your package name, suffixed by `.Tests` (i.e `Unity.[YourPackageName].Tests`) |
|||
* Assembly **must** reference `Unity.[YourPackageName]` |
|||
* Optional Unity references **must** include `"TestAssemblies"` to allow your Playmode Tests to show up in the Test Runner/run on Katana when your package is listed in project manifest `testables` |
|||
|
|||
> |
|||
> The reason for choosing such name schema is to ensure that the name of the assembly built based on *assembly definition file* (_a.k.a .asmdef_) will follow the .Net [Framework Design Guidelines](https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/index) |
|||
|
|||
1. ##### Document your package. |
|||
|
|||
**Document your public APIs** |
|||
* All public APIs need to be documented with XmlDoc. If you don't need an API to be accessed by clients, mark it as internal instead. |
|||
* API documentation is generated from [XmlDoc tags](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/xmldoc/xml-documentation-comments) included with all public APIs found in the package. See [Editor/EditorExample.cs](Editor/EditorExample.cs) for an example. |
|||
|
|||
**Document your features** |
|||
* All packages that expose UI in the editor or runtime features should use the documentation template in [Documentation/your-package-name.md](Documentation/your-package-name.md). |
|||
|
|||
**Documentation flow** |
|||
* Documentation needs to be ready when a publish request is sent to Release Management, as they will ask the documentation team to review it. |
|||
* The package will remain in `preview` mode until the final documentation is completed. Users will have access to the developer-generated documentation only in preview packages. |
|||
* When the documentation is completed, the documentation team will update the package git repo with the updates and they will publish it on the web. |
|||
* The package's development team will then need to submit a new package version with updated docs. |
|||
* The starting page in the user manual that links to package documentation is [Here](http://docs.hq.unity3d.com/2018.1/Documentation/Manual/PackagesList.html). |
|||
* The `Documentation~` folder is suffixed with `~` so that its content does not get loaded in the editor, which is the recommended behavior. If this is problematic, you can still name it `Documentation` and all tools will still work correctly. `.Documentation` is also supported. |
|||
|
|||
**Test your documentation locally** |
|||
As you are developing your documentation, you can see what your documentation will look like by using the [DocTools extension](https://gitlab.internal.unity3d.com/upm-packages/package-ux/package-manager-doctools) (optional). |
|||
Once the DocTools package is installed, it will add a `Generate Documentation` button in the Package Manager UI's details of your installed packages. To install the extension, follow these steps: |
|||
|
|||
1. Make sure you have `Package Manager UI v1.9.6` or above. |
|||
1. Your project manifest will need to point to a staging registry for this, which you can do by adding this line to it: `"registry": "https://staging-packages.unity.com"` |
|||
1. Install `Package Manager DocTools v1.0.0-preview.6` or above from the `Package Manager UI` (in the `All Packages` section). |
|||
1. After installation, you will see a `Generate Documentation` button which will generate the documentation locally, and open a web browser to a locally served version of your documentation so you can preview it. |
|||
1. (optional) If your package documentation contains multiple `.md` files for the user manual, see [this page](https://docs.unity3d.com/Packages/com.unity.package-manager-doctools@1.0/manual/index.html#table-of-content) to add a table of content to your documentation. |
|||
|
|||
The DocTools extension is still in preview, if you come across arguable results, please discuss them on #docs-packman. |
|||
|
|||
1. ##### Add samples to your package (code & assets). |
|||
If your package contains a sample, rename the `Samples/Example` folder, and update the `.sample.json` file in it. |
|||
|
|||
In the case where your package contains multiple samples, you can make a copy of the `Samples/Example` folder for each sample, and update the `.sample.json` file accordingly. |
|||
|
|||
Similar to `.tests.json` file, there is a `"createSeparatePackage"` field in `.sample.json`.If set to true, the CI will create an separate package for the sample.. |
|||
|
|||
Delete the `Samples` folder altogether if your package does not need samples. |
|||
|
|||
As of Unity release 2019.1, the /Samples directory of a package will be recognized by the package manager. Samples will not be imported to Unity when the package is added to a project, but will instead be offered to users of the package as an optional import, which can be added to their "/Assets" directory through a UI option. |
|||
|
|||
1. ##### Validate your package. |
|||
|
|||
**Validate your package using the Validation Suite** |
|||
Before you publish your package, you need to make sure that it passes all the necessary validation checks by using the [Package Validation Suite extension](https://gitlab.internal.unity3d.com/upm-packages/package-ux/package-validation-suite) (required). |
|||
Once the Validation Suite package is installed, it will add a `Validate` button in the Package Manager UI's details of your installed packages. To install the extension, follow these steps: |
|||
|
|||
1. Make sure you have `Package Manager UI v1.9.6` or above. |
|||
1. Your project manifest will need to point to a staging registry for this, which you can do by adding this line to it: `"registry": "https://staging-packages.unity.com"` |
|||
1. Install `Package Validation Suite v0.4.0-preview.2` or above from the `Package Manager UI` in the `All Packages` section. If you can't find it there, try turning on `Show preview packages` in the `Advanced` menu. |
|||
1. After installation, you will see a `Validate` button show up in the Package Manager UI, which, when pressed, will run a series of tests and expose a `See Results` button for additional explanation. |
|||
1. If it succeeds, you will see a green bar with a `Success` message. |
|||
1. If it fails, you will see a red bar with a `Failed` message. |
|||
|
|||
The validation suite is still in preview, if you come across arguable results, please discuss them on #release-management. |
|||
|
|||
1. ##### Design Guidelines. |
|||
|
|||
1. You should follow these design guideline when creating your package |
|||
1. [Package design guidelines](https://confluence.hq.unity3d.com/display/UX/Packages) |
|||
1. [Unity design checklist](https://unitytech.github.io/unityeditor-hig/topics/checklist.html) |
|||
|
|||
1. The namespace for code in the asmdef **must** match the asmdef name, except the initial `Unity`, which should be replaced with `UnityEngine` or `UnityEditor`: |
|||
1. Runtime codeWe should only use the `Unity` namespace for code that has no dependency on anything in `UnityEngine` or `UnityEditor` and instead uses `ECS` and other `Unity`-namespace systems. |
|||
|
|||
1. ##### Add tests to your package. |
|||
|
|||
**Editor tests** |
|||
* Write all your Editor Tests in `Tests/Editor` |
|||
* If your tests require access to internal methods, add an `AssemblyInfo.cs` file to your `Editor` code and use `[assembly: InternalsVisibleTo("Unity.[YourPackageName].Editor.Tests")]` |
|||
|
|||
**Playmode Tests** |
|||
* Write all your Playmode Tests in `Tests/Runtime`. |
|||
* If your tests require access to internal methods, add an `AssemblyInfo.cs` file to your `Runtime` code and use `[assembly: InternalsVisibleTo("Unity.[YourPackageName].RuntimeTests")]` |
|||
|
|||
1. ##### Update **CHANGELOG.md**. |
|||
|
|||
Every new feature or bug fix should have a trace in this file. For more details on the chosen changelog format, see [Keep a Changelog](http://keepachangelog.com/en/1.0.0/). |
|||
|
|||
## Create a Pre-Release Package |
|||
Pre-Release Packages are a great way of getting your features in front of Unity Developers in order to get early feedback on functionality and UI designs. Pre-Release packages need to go through the publishing to production flow, as would any other package, but with diminished requirements. Here are the supported Pre-Release tags (to be used in package.json,`version` field), along with the requirements for each one: |
|||
|
|||
**Preview** - ex: `"version" : "1.2.0-preview"` |
|||
* Expected Package structure respected |
|||
* Package loads in Unity Editor without errors |
|||
* License file present - With third party notices file if necessary |
|||
* Test coverage is good - Optional but preferred |
|||
* Public APIs documented, minimal feature docs exists- Optional but preferred |
|||
|
|||
## Register your package |
|||
|
|||
If you think you are working on a feature that is a good package candidate, please take a minute to fill-in this form: https://docs.google.com/forms/d/e/1FAIpQLSedxgDcIyf1oPyhWegp5FBvMm63MGAopeJhHDT5bU_BkFPNIQ/viewform?usp=sf_link. |
|||
|
|||
Working with the board of dev directors and with product management, we will schedule the entry of the candidates in the ecosystem, based on technical challenges and on our feature roadmap. |
|||
Don’t hesitate to reach out and join us on **#devs-packman** on Slack. |
|||
|
|||
## Share your package |
|||
|
|||
If you want to share your project with other developers, the steps are similar to what's presented above. On the other developer's machine: |
|||
|
|||
1. Start **Unity**, create a local empty project. |
|||
|
|||
1. Launch console (or terminal) application, go to the newly created project folder, then clone your repository in the packages directory |
|||
|
|||
```none |
|||
cd <YourProjectPath>/Packages |
|||
git clone https://gitlab.internal.unity3d.com/upm-packages/[sub-group]/[your-package-name].git com.unity.[sub-group].[your-package-name] |
|||
``` |
|||
__Note:__ Your directory name must be the name of your package (Example: `"com.unity.terrain-builder"`) |
|||
|
|||
## Make sure your package meets all legal requirements |
|||
|
|||
All packages are *required* to COMPLETE AND SUBMIT [THIS FORM](https://docs.google.com/forms/d/e/1FAIpQLSe3H6PARLPIkWVjdB_zMvuIuIVtrqNiGlEt1yshkMCmCMirvA/viewform) to receive approval. It is a simple, streamlined form that tells legal if there are any potential issues that need to be addressed prior to publication. |
|||
|
|||
##### Update **Third Party Notices.md** |
|||
|
|||
1. If your package has third-party elements and its licenses are approved, then all the licenses must be added to the `Third Party Notices.md` file. Simply duplicate the `Component Name/License Type/Provide License Details` section if you have more then one licenes. |
|||
|
|||
a. Concerning `[Provide License Details]` in the `Third Party Notices.md`, a URL can work as long as it actually points to the reproduced license and the copyright information _(if applicable)_. |
|||
|
|||
1. If your package does not have third party elements, you can remove the `Third Party Notices.md` file from your package. |
|||
|
|||
## Preparing your package for Staging |
|||
|
|||
Before publishing your package to production, you must send your package on the Package Manager's **staging** repository. The staging repository is monitored by QA and release management, and is where package validation will take place before it is accepted in production. |
|||
## *** IMPORTANT: The staging repository is publicly accessible, do not publish any packages with sensitive material you aren't ready to share with the public *** |
|||
|
|||
|
|||
1. Publishing your changes to the package manager's **staging** repository happens from Gitlab. To do so, simply setup your project's Continuous integration, which will be triggered by "Tags" on your branches. |
|||
* Join the **#devs-packman** channel on Slack, and request a staging **USERNAME** and **API_KEY**. |
|||
* In Gitlab, under the **Settings-> CI/CD -> Secret Variables** section, setup the following 2 project variables: |
|||
* API_KEY = [your API KEY] |
|||
* USER_NAME = [your USER NAME@unity] |
|||
* You're almost done! To publish a version of your package, make sure all your changes are checked into Gitlab, then create a new tag to reflect the version you are publishing (ex. "v1.2.2"), **the tag will trigger a publish to Staging**. You can view progress you the publish request by switch over to the "CI / CD" part of your project. |
|||
|
|||
1. Do it yourself CI |
|||
|
|||
If you are using your own CI, it is still recommended that you use the `build.sh` wrapper script that comes with the starter kit, as it handle the installation of the actual CI build scripts for you. |
|||
|
|||
Instead of calling `npm pack` and `npm publish` in the package root folder in your CI, use |
|||
``` |
|||
./build.sh package-ci pack --git-head $CI_COMMIT_SHA --git-url $CI_REPOSITORY_URL |
|||
``` |
|||
and |
|||
``` |
|||
./build.sh package-ci publish --git-head $CI_COMMIT_SHA --git-url $CI_REPOSITORY_URL |
|||
``` |
|||
respectively. |
|||
|
|||
1. Test your package locally |
|||
|
|||
Now that your package is published on the package manager's **staging** repository, you can test your package in the editor by creating a new project, and editing the project's `manifest.json` file to point to your staging package, as such: |
|||
``` |
|||
dependencies: { |
|||
"com.unity.[sub-group].[your-package-name]": "0.1.0" |
|||
}, |
|||
"registry": "https://staging-packages.unity.com" |
|||
``` |
|||
|
|||
## Get your package published to Production |
|||
|
|||
Packages are promoted to the **production** repository from **staging**, described above. Certain criteria must be met before submitting a request to promote a package to production. |
|||
[The list of criteria can be found here](https://docs.google.com/document/d/1TSnlSKJ6_h0C-CYO2LvV0fyGxJvH6OxC2-heyN8o-Gw/edit#heading=h.xxfb5jk2jda2) |
|||
|
|||
Once you feel comfortable that your package meets the list of Release Management Criteria, [Submit your package publishing request to Release Management](https://docs.google.com/forms/d/e/1FAIpQLSdSIRO6s6_gM-BxXbDtdzIej-Hhk-3n68xSyC2sM8tp7413mw/viewform). |
|||
|
|||
**Release management will validate your package content, and check that the editor/playmode tests are passed before promoting the package to production. You will receive a confirmation email once the package is in production.** |
|||
|
|||
**You're not done!** |
|||
At this point, your package is available on the cloud, 2 more steps are required to make your package discoverable in the editor: |
|||
|
|||
1. Contact the Package Manager team in #devs-packman to ask them to add your package to the list of discoverable package for the Unity Editor. All you need to provide is the package name (com.unity.[sub-group].[your-package-name]) |
|||
1. If your package is meant to ship with a release of the editor (Unity Recommended Packages), follow these steps: |
|||
* Modify the editor manifest ``[root]\External\PackageManager\Editor\Manifest.json`` to include your package in the list of dependencies. |
|||
* Submit one or more Test Project(s) in Ono, so that your new package can be tested in all ABVs moving forward. The following steps will create a test project that will run in ABVs, load your package into the project, and run all the tests found in your package. The better your test coverage, the more confident you'll be that your package works with trunk. |
|||
* Create a branch in Ono, based on the latest branch this package must be compatible with (trunk, or release branch) |
|||
* If your package contains **Editor Tests**: |
|||
* In ``[root]\Tests\Editor.Tests``, create a new EditorTest Project (for new packages use **YourPackageName**) or use an existing project (for new versions of existing package). |
|||
* A [skeleton of EditorTest Project can be found here](https://oc.unity3d.com/index.php/s/Cldvuy6NpxqYy8y). |
|||
* Modify the project’s manifest.json file to include the production version of the package (name@version). |
|||
* Your project's manifest.json file should contain the following line: ``"testables" : [ "com.unity.[sub-group].[your-package-name]" ]`` |
|||
* If your package contains **PlaymodeTests**: |
|||
* In ``[root]\Tests\PlaymodeTests``, create a new PlaymodeTest Project (for new packages use **YourPackageName**) or use an existing project (for new versions of existing package). |
|||
* Modify the project’s manifest.json file to include the staging version of the package (name@version). |
|||
* Your project's manifest.json file should contain the following line: ``"testables" : [ "com.unity.[sub-group].[your-package-name]" ]``. |
|||
* Commit your branch changes to Ono, and run all Windows & Mac Editor/PlayMode tests (not full ABV) in Katana. |
|||
* Once the tests are green on Katana, create your PR, add both `Latest Release Manager` and `Trunk Merge Queue` as reviewers. |
|||
|
|||
|
|||
## FAQ |
|||
|
|||
**What’s the difference between a preview package and a verified package?** |
|||
|
|||
A preview package is a great way to develop and get feedback on new features and functionality. Preview package can be created against any version of Unity 2018.1+, and can be made discoverable through the Package Manager UI by issuing a request in #devs-packman. Quality and release schedule is up to the package owner, although minimum bars are set in place to ensure the package contains the right licenses, documentation, and a comprehensive set of tests. |
|||
|
|||
Once a preview package has been in the field for 2-3 release cycles of the editor, that package can be considered for Verification. Verified packages are tested with a specific version of the editor, and offer our users a compatibility guarantee. Verified packages are the only packages that can be included in the set of templates we ship with the editor (Verified Templates). Code for these packages must follow core development guidelines, including code cutoff dates, and are tested in katana for continued compatibility. |
|||
|
|||
**What’s the difference between a core package and a default package?** |
|||
|
|||
A core package is a package that has its code included with the Editor’s core code. This is interesting for packages that plan to change enormously in parallel to editor APIs. By moving package code to the editor’s repo, both core API\functionality changes can be made along with required packages changes in the same PR. |
|||
https://docs.google.com/document/d/1CMoanjR3KAdew-6n39JdCFmHkTp1oshs3vkpejapf4Q/edit |
|||
|
|||
A default package is a verified packages that gets installed with every new project users create, regardless of the template they use. We should limit the number of default packages we support, as each default package adds to the project loading time. The list of default packages can be found in the editor manifest (https://ono.unity3d.com/unity/unity/files/de904b9ed9b44580ecd1e883f510daaa08182cc5/External/PackageManager/Editor/manifest.json). |
|||
|
|||
**What are the requirement for me to publish a preview package?** |
|||
|
|||
https://docs.google.com/document/d/1epGkAJRayJLN89_weA_-G5LFT_1uFifFZqBzAgvp_Zs/ |
|||
|
|||
|
|||
**What are the requirements for me to get my package verified for a version of unity?** |
|||
|
|||
https://docs.google.com/document/d/1oWC9XArVfkGMnqN9azR4hW4Pcd7-kQQw8Oy7ckP43JE/ |
|||
|
|||
**How is my verified package tested in Katana?** |
|||
|
|||
https://docs.google.com/document/d/1jwTh71ZGtB2vF0SsHEwivt2FunaJWMGDdQJTpYRj3EE/edit |
|||
|
|||
**How is my template tested in Katana?** |
|||
|
|||
https://docs.google.com/document/d/1jwTh71ZGtB2vF0SsHEwivt2FunaJWMGDdQJTpYRj3EE/edit |
|||
|
|||
**How do I add samples to my package?** |
|||
|
|||
https://docs.google.com/document/d/1rmxGh6Z9gtbQlGUKCsVBaR0RyHvzq_gsWoYs6sttzYA/edit#heading=h.fg1e3sz56048 |
|||
|
|||
**How can I add tests to my package?** |
|||
|
|||
There’s a “Tests” directory in the package starter kit. If you add editor and playmode tests in that directory, they will make up the list of tests for your package. |
|||
|
|||
**The tests in my package bloat my package too much, what are my options?** |
|||
|
|||
https://docs.google.com/document/d/19kKIGFetde5ES-gKXQp_P7bxQ9UgBnBUu58-y7c1rTA/edit |
|||
|
|||
**Can I automate my package publishing yet?** |
|||
|
|||
Not just yet, but we’re working on it. The first automated publishing we will enable is the push to production for preview packages. Basically, when your package passes validation (loads in the editor without error, the tests in the package pass, validation suite run success), the package will be pushed to production automatically. Other publishing flows will soon be available as well, here’s the full list of internal package publishing flows Unity will support. https://docs.google.com/document/d/1zdMzAtfi-vgM8NMPmwL40yinBeL3YImwTO5gSfGNCgs/edit |
|||
|
|||
**How do I get a template package started?** |
|||
|
|||
Start with the Project Template Starter Kit (you can request access in #devs-packman). |
|||
https://gitlab.internal.unity3d.com/upm-packages/project-templates/project-template-starter-kit |
|||
|
|||
**How do I get my package included in a template?** |
|||
|
|||
First and foremost, your package needs to be on the verified list of packages. Only verified packages can get added to templates we ship with the editor. Then reach out to the templates community in #devs-template to open discussions on adding your package to one or more of our existing templates. |
|||
|
|||
**How can I test my package locally, as a user would?** |
|||
|
|||
https://confluence.hq.unity3d.com/display/PAK/How+to+add+a+git+package+to+your+project |
|||
|
|||
**What tests are included by the validation suite?** |
|||
|
|||
https://docs.google.com/spreadsheets/d/1CdO7D0WSirbZhjnVsdJxJwOPK4UdUDxSRBIqwyjm70w/edit#gid=0 |
|
|||
# UPM Package Starter Kit |
|||
|
|||
The purpose of this starter kit is to provide the data structure and development guidelines for new packages meant for the **Unity Package Manager (UPM)**. |
|||
|
|||
## Are you ready to become a package? |
|||
The Package Manager is a work-in-progress for Unity and, in that sense, there are a few criteria that must be met for your package to be considered on the package list at this time: |
|||
- **Your code accesses public Unity C# APIs only.** If you have a native code component, it will need to ship with an official editor release. Internal API access might eventually be possible for Unity made packages, but not at this time. |
|||
- **Your code doesn't require security, obfuscation, or conditional access control.** Anyone should be able to download your package and access the source code. |
|||
|
|||
|
|||
## Package structure |
|||
|
|||
```none |
|||
<root> |
|||
├── package.json |
|||
├── README.md |
|||
├── CHANGELOG.md |
|||
├── LICENSE.md |
|||
├── Third Party Notices.md |
|||
├── QAReport.md |
|||
├── Editor |
|||
│ ├── Unity.[YourPackageName].Editor.asmdef |
|||
│ └── EditorExample.cs |
|||
├── Runtime |
|||
│ ├── Unity.[YourPackageName].asmdef |
|||
│ └── RuntimeExample.cs |
|||
├── Tests |
|||
│ ├── .tests.json |
|||
│ ├── Editor |
|||
│ │ ├── Unity.[YourPackageName].Editor.Tests.asmdef |
|||
│ │ └── EditorExampleTest.cs |
|||
│ └── Runtime |
|||
│ ├── Unity.[YourPackageName].Tests.asmdef |
|||
│ └── RuntimeExampleTest.cs |
|||
├── Samples |
|||
│ └── Example |
|||
│ ├── .sample.json |
|||
│ └── SampleExample.cs |
|||
└── Documentation~ |
|||
├── your-package-name.md |
|||
└── Images |
|||
``` |
|||
|
|||
## Develop your package |
|||
Package development works best within the Unity Editor. Here's how to set that up: |
|||
|
|||
1. Start **Unity**, create a local empty project. |
|||
|
|||
1. In a console (or terminal) application, go to the newly created project folder, then copy the contents of this starter kit into the packages directory. |
|||
__Note:__ Your directory name must be the name of your package (Example: `"com.unity.terrain-builder"`) |
|||
|
|||
1. ##### Fill in your package information |
|||
|
|||
Update the following required fields in file **package.json**: |
|||
- `"name"`: Package name, it should follow this naming convention: `"com.[YourCompanyName].[sub-group].[your-package-name]"` |
|||
(Example: `"com.unity.2d.animation"`, where `sub-group` should match the sub-group you selected in Gitlab) |
|||
- `"displayName"`: Package user friendly display name. (Example: `"Terrain Builder SDK"`). <br>__Note:__ Use a display name that will help users understand what your package is intended for. |
|||
- `"version"`: Package version `"X.Y.Z"`, your project **must** adhere to [Semantic Versioning](http://semver.org/spec/v2.0.0.html). |
|||
Follow this guideline: |
|||
- To introduce a new feature or bug fix, increment the minor version (X.**Y**.Z) |
|||
- To introduce a breaking API change, increment the major version (**X**.Y.Z) |
|||
- The patch version (X.Y.**Z**), is reserved for sustainable engineering use only. |
|||
- `"unity"`: Unity Version your package is compatible with. (Example: `"2018.1"`) |
|||
- `"description"`: This description appears in the Package Manager window when the user selects this package from the list. For best results, use this text to summarize what the package does and how it can benefit the user.<br>__Note:__ Special formatting characters are supported, including line breaks (`\n`) and unicode characters such as bullets (`\u25AA`).<br> |
|||
|
|||
Update the following recommended fields in file **package.json**: |
|||
- `"dependencies"`: List of packages this package depends on. All dependencies will also be downloaded and loaded in a project with your package. Here's an example: |
|||
``` |
|||
dependencies: { |
|||
"com.unity.ads": "1.0.0" |
|||
"com.unity.analytics": "2.0.0" |
|||
} |
|||
``` |
|||
- `"keywords"`: List of words that will be indexed by the package manager search engine to facilitate discovery. |
|||
|
|||
Update the following field in file **Tests/.tests.json**: |
|||
- `"createSeparatePackage"`: If this is set to true, the CI will create an separate package for these tests. |
|||
|
|||
1. You should now see your package in the Project Window, along with all other available packages for your project. |
|||
|
|||
1. ##### Rename and update assembly definition files. |
|||
|
|||
Assembly definition files are used to generate C# assemblies during compilation. Package code must include asmdef files to ensure package code isolation. You can read up on assembly definition files [here](https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html). |
|||
|
|||
If your package contains Editor code, rename and modify [Editor/Unity.YourPackageName.Editor.asmdef](Editor/Unity.YourPackageName.Editor.asmdef). Otherwise, delete the Editor directory. |
|||
* Name **must** match your package name, suffixed by `.Editor` (i.e `Unity.[YourPackageName].Editor`) |
|||
* Assembly **must** reference `Unity.[YourPackageName]` (if you have any Runtime) |
|||
* Platforms **must** include `"Editor"` |
|||
|
|||
If your package contains code that needs to be included in Unity runtime builds, rename and modify [Runtime/Unity.YourPackageName.asmdef](Runtime/Unity.YourPackageName.asmdef). Otherwise, delete the Runtime directory. |
|||
* Name **must** match your package name (i.e `Unity.[YourPackageName]`) |
|||
|
|||
If your package has Editor code, you **must** include Editor Tests in your package. In that case, rename and modify [Tests/Editor/Unity.YourPackageName.Editor.Tests.asmdef](Tests/Editor/Unity.YourPackageName.Editor.Tests.asmdef). |
|||
* Name **must** match your package name, suffixed by `.Editor.Tests` (i.e `Unity.[YourPackageName].Editor.Tests`) |
|||
* Assembly **must** reference `Unity.[YourPackageName].Editor` and `Unity.[YourPackageName]` (if you have any Runtime) |
|||
* Platforms **must** include `"Editor"` |
|||
* Optional Unity references **must** include `"TestAssemblies"` to allow your Editor Tests to show up in the Test Runner/run on Katana when your package is listed in project manifest `testables` |
|||
|
|||
If your package has Runtime code, you **must** include Playmode Tests in your package. In that case, rename and modify [Tests/Runtime/Unity.YourPackageName.Tests.asmdef](Tests/Runtime/Unity.YourPackageName.Tests.asmdef). |
|||
* Name **must** match your package name, suffixed by `.Tests` (i.e `Unity.[YourPackageName].Tests`) |
|||
* Assembly **must** reference `Unity.[YourPackageName]` |
|||
* Optional Unity references **must** include `"TestAssemblies"` to allow your Playmode Tests to show up in the Test Runner/run on Katana when your package is listed in project manifest `testables` |
|||
|
|||
> |
|||
> The reason for choosing such name schema is to ensure that the name of the assembly built based on *assembly definition file* (_a.k.a .asmdef_) will follow the .Net [Framework Design Guidelines](https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/index) |
|||
|
|||
1. ##### Document your package. |
|||
|
|||
Rename and update **your-package-name.md** documentation file. Use this documentation template file to create preliminary, high-level documentation. This document is meant to introduce users to the features and sample files included in your package. Your package documentation files will be used to generate online and local docs, available from the package manager UI. |
|||
|
|||
**Document your public APIs** |
|||
* All public APIs need to be documented with XmlDoc. If you don't need an API to be accessed by clients, mark it as internal instead. |
|||
* API documentation is generated from [XmlDoc tags](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/xmldoc/xml-documentation-comments) included with all public APIs found in the package. See [Editor/EditorExample.cs](Editor/EditorExample.cs) for an example. |
|||
|
|||
**Documentation flow** |
|||
* Documentation needs to be ready when a publish request is sent to Release Management, as they will ask the documentation team to review it. |
|||
* The package will remain in `preview` mode until the final documentation is completed. Users will have access to the developer-generated documentation only in preview packages. |
|||
* When the documentation is completed, the documentation team will update the package git repo with the updates and they will publish it on the web. |
|||
* The package's development team will then need to submit a new package version with updated docs. |
|||
* The starting page in the user manual that links to package documentation is [Here](https://docs.unity3d.com/Manual/PackagesList.html). |
|||
* The `Documentation~` folder is suffixed with `~` so that its content does not get loaded in the editor, which is the recommended behavior. If this is problematic, you can still name it `Documentation` and all tools will still work correctly. `.Documentation` is also supported. |
|||
|
|||
**Test your documentation locally** |
|||
As you are developing your documentation, you can see what your documentation will look like by using the DocTools extension (optional). |
|||
Once the DocTools package is installed, it will add a `Generate Documentation` button in the Package Manager UI's details of your installed packages. To install the extension, follow these steps: |
|||
|
|||
1. Make sure you have `Package Manager UI v1.9.6` or above. |
|||
1. Your project manifest will need to point to a staging registry for this, which you can do by adding this line to it: `"registry": "https://staging-packages.unity.com"` |
|||
1. Install `Package Manager DocTools v1.0.0-preview.6` or above from the `Package Manager UI` (in the `All Packages` section). |
|||
1. After installation, you will see a `Generate Documentation` button which will generate the documentation locally, and open a web browser to a locally served version of your documentation so you can preview it. |
|||
1. (optional) If your package documentation contains multiple `.md` files for the user manual, see [this page](https://docs.unity3d.com/Packages/com.unity.package-manager-doctools@1.0/manual/index.html#table-of-content) to add a table of content to your documentation. |
|||
|
|||
The DocTools extension is still in preview, if you come across arguable results, please discuss them on #docs-packman. |
|||
|
|||
1. ##### Add samples to your package (code & assets). |
|||
If your package contains a sample, rename the `Samples/Example` folder, and update the `.sample.json` file in it. |
|||
|
|||
In the case where your package contains multiple samples, you can make a copy of the `Samples/Example` folder for each sample, and update the `.sample.json` file accordingly. |
|||
|
|||
Similar to `.tests.json` file, there is a `"createSeparatePackage"` field in `.sample.json`.If set to true, the CI will create an separate package for the sample.. |
|||
|
|||
Delete the `Samples` folder altogether if your package does not need samples. |
|||
|
|||
As of Unity release 2019.1, the /Samples directory of a package will be recognized by the package manager. Samples will not be imported to Unity when the package is added to a project, but will instead be offered to users of the package as an optional import, which can be added to their "/Assets" directory through a UI option. |
|||
|
|||
1. ##### Validate your package. |
|||
|
|||
Before you publish your package, you need to make sure that it passes all the necessary validation checks by using the Package Validation Suite extension (optional). |
|||
Once the Validation Suite package is installed, it will add a `Validate` button in the Package Manager UI's details of your installed packages. To install the extension, follow these steps: |
|||
|
|||
1. Make sure you have `Package Manager UI v1.9.6` or above. |
|||
1. Your project manifest will need to point to a staging registry for this, which you can do by adding this line to it: `"registry": "https://staging-packages.unity.com"` |
|||
1. Install `Package Validation Suite v0.3.0-preview.13` or above from the `Package Manager UI` in the `All Packages` section. If you can't find it there, try turning on `Show preview packages` in the `Advanced` menu. |
|||
1. After installation, you will see a `Validate` button show up in the Package Manager UI, which, when pressed, will run a series of tests and expose a `See Results` button for additional explanation. |
|||
1. If it succeeds, you will see a green bar with a `Success` message. |
|||
1. If it fails, you will see a red bar with a `Failed` message. |
|||
|
|||
The validation suite is still in preview, if you come across arguable results, please discuss them on #release-management. |
|||
|
|||
1. ##### Add tests to your package. |
|||
|
|||
All packages must contain tests. Tests are essential for Unity to ensure that the package works as expected in different scenarios. |
|||
|
|||
**Editor tests** |
|||
* Write all your Editor Tests in `Tests/Editor` |
|||
|
|||
**Playmode Tests** |
|||
* Write all your Playmode Tests in `Tests/Runtime`. |
|||
|
|||
1. ##### Update **CHANGELOG.md**. |
|||
|
|||
Every new feature or bug fix should have a trace in this file. For more details on the chosen changelog format, see [Keep a Changelog](http://keepachangelog.com/en/1.0.0/). |
|||
|
|||
## Create a Pre-Release Package |
|||
Pre-Release Packages are a great way of getting your features in front of Unity Developers in order to get early feedback on functionality and UI designs. Pre-Release packages need to go through the publishing to production flow, as would any other package, but with diminished requirements. Here are the supported Pre-Release tags (to be used in package.json,`version` field), along with the requirements for each one: |
|||
|
|||
**Preview** - ex: `"version" : "1.2.0-preview"` |
|||
* Expected Package structure respected |
|||
* Package loads in Unity Editor without errors |
|||
* License file present - With third party notices file if necessary |
|||
* Test coverage is good - Optional but preferred |
|||
* Public APIs documented, minimal feature docs exists- Optional but preferred |
|||
|
|||
## Make sure your package meets all legal requirements |
|||
|
|||
##### Update **Third Party Notices.md** & **License.md** |
|||
|
|||
1. If your package has third-party elements and its licenses are approved, then all the licenses must be added to the `Third Party Notices.md` file. Simply duplicate the `Component Name/License Type/Provide License Details` section if you have more then one licenes. |
|||
|
|||
a. Concerning `[Provide License Details]` in the `Third Party Notices.md`, a URL can work as long as it actually points to the reproduced license and the copyright information _(if applicable)_. |
|||
|
|||
1. If your package does not have third party elements, you can remove the `Third Party Notices.md` file from your package. |
|||
|
|||
## Preparing your package for Staging |
|||
|
|||
Before publishing your package to production, you must send your package on the Package Manager's **staging** repository. The staging repository is monitored by QA and release management, and is where package validation will take place before it is accepted in production. |
|||
## *** IMPORTANT: The staging repository is publicly accessible, do not publish any packages with sensitive material you aren't ready to share with the public *** |
|||
|
|||
|
|||
1. Publishing your changes to the package manager's **staging** repository happens from Gitlab. To do so, simply setup your project's Continuous integration, which will be triggered by "Tags" on your branches. |
|||
* Join the **#devs-packman** channel on Slack, and request a staging **USERNAME** and **API_KEY**. |
|||
* In Gitlab, under the **Settings-> CI/CD -> Secret Variables** section, setup the following 2 project variables: |
|||
* API_KEY = [your API KEY] |
|||
* USER_NAME = [your USER NAME@unity] |
|||
* You're almost done! To publish a version of your package, make sure all your changes are checked into Gitlab, then create a new tag to reflect the version you are publishing (ex. "v1.2.2"), **the tag will trigger a publish to Staging**. You can view progress you the publish request by switch over to the "CI / CD" part of your project. |
|||
|
|||
1. Do it yourself CI |
|||
|
|||
If you are using your own CI, it is still recommended that you use the `build.sh` wrapper script that comes with the starter kit, as it handle the installation of the actual CI build scripts for you. |
|||
|
|||
Instead of calling `npm pack` and `npm publish` in the package root folder in your CI, use |
|||
``` |
|||
./build.sh package-ci pack --git-head $CI_COMMIT_SHA --git-url $CI_REPOSITORY_URL |
|||
``` |
|||
and |
|||
``` |
|||
./build.sh package-ci publish --git-head $CI_COMMIT_SHA --git-url $CI_REPOSITORY_URL |
|||
``` |
|||
respectively. |
|||
|
|||
1. Test your package locally |
|||
|
|||
Now that your package is published on the package manager's **staging** repository, you can test your package in the editor by creating a new project, and editing the project's `manifest.json` file to point to your staging package, as such: |
|||
``` |
|||
dependencies: { |
|||
"com.[YourCompanyName].[sub-group].[your-package-name]": "0.1.0" |
|||
}, |
|||
"registry": "https://staging-packages.unity.com" |
|||
``` |
|||
|
|||
## Get your package published to Production |
|||
|
|||
Packages are promoted to the **production** repository from **staging**, described above. |
|||
|
|||
Once you feel comfortable that your package is ready for prime time, and passes validation (Validation Suite), reach out to Unity so your package can be passed along to Release Management, for evaluation. |
|||
|
|||
**Release management will validate your package content, and check that the editor/playmode tests are passed before promoting the package to production. You will receive a confirmation email once the package is in production.** |
|||
|
|||
**You're almost done!** |
|||
At this point, your package is available on the cloud, but not discoverable through the editor: |
|||
|
|||
1. Contact the Package Manager team to ask them to add your package to the list of discoverable package for the Unity Editor. All you need to provide is the package name (com.[YourCompanyName].[sub-group].[your-package-name]) |
|
|||
image: node:6.10.0 |
|||
|
|||
variables: |
|||
BINTRAY_STAGING: 'https://staging-packages.unity.com' |
|||
|
|||
before_script: |
|||
- chmod +x build.sh |
|||
|
|||
stages: |
|||
- push_to_packman_staging |
|||
|
|||
push_to_packman_staging: |
|||
stage: push_to_packman_staging |
|||
only: |
|||
- tags |
|||
script: |
|||
- ./build.sh npm auth "$BINTRAY_STAGING" "$USER_NAME" "$API_KEY" |
|||
- ./build.sh package-ci publish --git-head $CI_COMMIT_SHA --git-url $CI_REPOSITORY_URL |
|
|||
artifacts/** |
|||
build/** |
|||
.build_script/** |
|||
node_modules/** |
|||
Documentation/ApiDocs/** |
|||
Documentation~/ApiDocs/** |
|||
.DS_Store |
|||
.npmrc |
|||
.npmignore |
|||
.gitignore |
|||
CONTRIBUTING.md |
|||
CONTRIBUTING.md.meta |
|||
QAReport.md |
|||
QAReport.md.meta |
|||
.gitlab-ci.yml |
|||
build.sh |
|||
build.sh.meta |
|||
build.bat |
|||
build.bat.meta |
|
|||
fileFormatVersion: 2 |
|||
guid: a0fac15a299ee4055badd11243f1b42e |
|||
folderAsset: yes |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: ac5a64474dd7f4ec78203c0d61fc0597 |
|||
folderAsset: yes |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
# Changelog |
|||
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). |
|||
|
|||
## [0.1.0] - 2017-MM-DD |
|||
|
|||
### This is the first release of *Unity Package \<Your package name\>*. |
|||
|
|||
*Short description of this release* |
|
|||
fileFormatVersion: 2 |
|||
guid: 522d519f4b74c4c28a5079ec64c78e4d |
|||
TextScriptImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
# Contributing |
|||
|
|||
## If you are interested in contributing, here are some ground rules: |
|||
* ... Define guidelines & rules for what contributors need to know to successfully make Pull requests against your repo ... |
|||
|
|||
## All contributions are subject to the [Unity Contribution Agreement(UCA)](https://unity3d.com/legal/licenses/Unity_Contribution_Agreement) |
|||
By making a pull request, you are confirming agreement to the terms and conditions of the UCA, including that your Contributions are your original creation and that you have complete right and authority to make your Contributions. |
|||
|
|||
## Once you have a change ready following these ground rules. Simply make a pull request |
|
|||
fileFormatVersion: 2 |
|||
guid: d5079cbdd40a34d6e966a9cb9e355f76 |
|||
TextScriptImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 8c3d3cc93dd04445ea15339f8ad7482e |
|||
folderAsset: yes |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
[MyPackageName] copyright © [YEAR] Unity Technologies ApS |
|||
|
|||
Licensed under the Unity Companion License for Unity-dependent projects--see [Unity Companion License](http://www.unity3d.com/legal/licenses/Unity_Companion_License). |
|||
|
|||
Unless expressly provided otherwise, the Software under this license is made available strictly on an “AS IS” BASIS WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. Please review the license for details on these and other terms and conditions. |
|
|||
fileFormatVersion: 2 |
|||
guid: f77549dfdff0141cf93f22327b7d1feb |
|||
TextScriptImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 293317a3a72e54b97ba6778f397ed4d3 |
|||
folderAsset: yes |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: f8bc74fee7ec6430a92e0ecef657dc81 |
|||
TextScriptImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: fdd664f0957bb49de899fc89820d4e58 |
|||
folderAsset: yes |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 9ec3b31e273be4fa494f51235f2ada88 |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 45e9425949dd54d51b93419f3ab2c5c4 |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: c8cdba411bb15401ab1683eff7c2c2e6 |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 2087756537fee4914b769699023471bb |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 4c30d1d3178334439a51b9eeead0da4e |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: b0d539408a2c64bca885682355645611 |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 605341af9d51749498ced677895b91ed |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: c13c2649a33f047ce9773bbd0db7be06 |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: aaa4e154704cb40e086ff59b367490c7 |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: c386b5311066f4d3c8f54295950ea755 |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 2b5292f75eeb045399fac7b9c553f192 |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: ff7c87aa985e74a0497941b0496159fd |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 69ebe0967786d45c787a140f1261d14c |
|||
TextScriptImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 1053ed4a29f954af8a57771b1402b908 |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 72572b0c3786b42ea92944c58119f1f3 |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: d07a3551c35cc492c82ec058b8185e8d |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: eeb541729616445208fa227412b0b829 |
|||
NativeFormatImporter: |
|||
externalObjects: {} |
|||
mainObjectFileID: 0 |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
# Quality Report |
|||
Use this file to outline the test strategy for this package. |
|||
|
|||
## Version tested: [*package version*] |
|||
|
|||
## QA Owner: [*Add Name*] |
|||
## UX Owner: [*Add Name*] |
|||
|
|||
## Test strategy |
|||
*Use this section to describe how this feature was tested.* |
|||
* A link to the Test Plan (Test Rails, other) |
|||
* Results from the package's editor and runtime test suite. |
|||
* Link to automated test results (if any) |
|||
* Manual test Results, [here's an example](https://docs.google.com/spreadsheets/d/12A76U5Gf969w10KL4Ik0wC1oFIBDUoRrqIvQgD18TFo/edit#gid=0) |
|||
* Scenario test week outcome |
|||
* etc. |
|||
|
|||
## Package Status |
|||
Use this section to describe: |
|||
* UX status/evaluation results |
|||
* package stability |
|||
* known bugs, issues |
|||
* performance metrics, |
|||
* etc |
|||
|
|||
In other words, a general feeling on the health of this package. |
|
|||
fileFormatVersion: 2 |
|||
guid: f19a98a9c074242b6908ab1bddaa66ca |
|||
TextScriptImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 1f81db83864a64e1787884fbd1e25cba |
|||
TextScriptImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: efe238f8645004af69998c3abf6eb3bf |
|||
folderAsset: yes |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 0e34324ad02e6491bb2e3ba81ff7b7df |
|||
folderAsset: yes |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 07e384a2d3b6c4ad6b1c07140c686a33 |
|||
folderAsset: yes |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
This package contains third-party software components governed by the license(s) indicated below: |
|||
--------- |
|||
|
|||
Component Name: [provide component name] |
|||
|
|||
License Type: [Provide license type, i.e. "MIT", "Apache 2.0"] |
|||
|
|||
[Provide License Details] |
|||
|
|||
--------- |
|||
Component Name: [provide component name] |
|||
|
|||
License Type: [Provide license type, i.e. "MIT", "Apache 2.0"] |
|||
|
|||
[Provide License Details] |
|||
|
|
|||
fileFormatVersion: 2 |
|||
guid: 91b9be9cd98a141278c4884aa6446901 |
|||
TextScriptImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
@ECHO OFF |
|||
|
|||
REM Wrapper script to make running the node.js CI script a little quicker. |
|||
REM Arguments are same as for index.js |
|||
|
|||
SET BUILD_SCRIPT="./.build_script/node_modules/upm-template-utils/index.js" |
|||
|
|||
IF NOT EXIST %BUILD_SCRIPT% ( |
|||
mkdir "./.build_script/node_modules" >NUL |
|||
CD .build_script |
|||
CALL npm install upm-template-utils --registry https://api.bintray.com/npm/unity/unity-staging --no-save --loglevel error >NUL |
|||
CD .. |
|||
) |
|||
|
|||
IF "%1" == "" ( |
|||
node %BUILD_SCRIPT% |
|||
) ELSE ( |
|||
node %BUILD_SCRIPT% %* |
|||
) |
|
|||
fileFormatVersion: 2 |
|||
guid: 9551e4091df864fc0a2b9d8b6e324e2e |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
#!/bin/sh |
|||
|
|||
BUILD_SCRIPT="./.build_script/node_modules/upm-template-utils/index.js" |
|||
|
|||
if [ ! -f $BUILD_SCRIPT ]; then |
|||
mkdir -p "./.build_script/node_modules" |
|||
cd .build_script |
|||
npm install upm-template-utils --registry https://api.bintray.com/npm/unity/unity-staging --no-save --loglevel error >/dev/null |
|||
cd .. |
|||
fi |
|||
|
|||
if [ -z $1 ]; then |
|||
node $BUILD_SCRIPT |
|||
else |
|||
node $BUILD_SCRIPT $* |
|||
fi |
|
|||
fileFormatVersion: 2 |
|||
guid: ea964234d2ddc42d9b625244d96bb27d |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
{ |
|||
"name": "com.unity.uiwidgets", |
|||
"displayName":"UI Widgets", |
|||
"version": "0.1.0-preview", |
|||
"unity": "2018.3", |
|||
"description": "Replace this string with your own description of the package. This description appears in the Package Manager window when the user selects this package from the list. \n\nFor best results, use this text to summarize: \n\u25AA What the package does \n\u25AA How it can benefit the user \n\nNote: Special formatting characters are supported, including line breaks ('\\n') and bullets ('\\u25AA').", |
|||
"dependencies": { |
|||
} |
|||
} |
|
|||
fileFormatVersion: 2 |
|||
guid: 98f4768c9e1754bee9b7438f40b2b854 |
|||
TextScriptImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 4b06650fb3b6d4b738815827309fb1aa |
|||
folderAsset: yes |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 673818c5a2b2446e4b1ed1c401479920 |
|||
folderAsset: yes |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: a78828f96e17445b2a7ae72473d87890 |
|||
MonoImporter: |
|||
externalObjects: {} |
|||
serializedVersion: 2 |
|||
defaultReferences: [] |
|||
executionOrder: 0 |
|||
icon: {instanceID: 0} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 1023a28dd4b7548da85b2c181757f57d |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 959a843c15d034cefaa96d9608f76fa7 |
|||
TextScriptImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 0757430e2307c4512890227833bae700 |
|||
MonoImporter: |
|||
externalObjects: {} |
|||
serializedVersion: 2 |
|||
defaultReferences: [] |
|||
executionOrder: 0 |
|||
icon: {instanceID: 0} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
>>> |
|||
**_Package Documentation Template_** |
|||
|
|||
Use this template to create preliminary, high-level documentation meant to introduce users to the feature and the sample files included in this package. When writing your documentation, do the following: |
|||
|
|||
1. Follow instructions in blockquotes. |
|||
|
|||
2. Replace angle brackets with the appropriate text. For example, replace "<package name>" with the official name of the package. |
|||
|
|||
3. Delete sections that do not apply to your package. For example, a package containing only sample files does not have a "Using <package_name>" section, so this section can be removed. |
|||
|
|||
4. After documentation is completed, make sure you delete all instructions and examples in blockquotes including this preamble and its title: |
|||
|
|||
``` |
|||
>>> |
|||
Delete all of the text between pairs of blockquote markdown. |
|||
>>> |
|||
``` |
|||
>>> |
|||
|
|||
# About <package name> |
|||
|
|||
>>> |
|||
Name the heading of the first topic after the **displayName** of the package as it appears in the package manifest. Check with your Product Manager to ensure that the package is named correctly. |
|||
|
|||
This first topic includes a brief, high-level explanation of the package and, if applicable, provides links to Unity Manual topics. |
|||
|
|||
There are two types of packages: |
|||
|
|||
- Packages that include features that augment the Unity Editor or Runtime. |
|||
- Packages that include sample files. |
|||
|
|||
Choose one of the following introductory paragraphs that best fits the package: |
|||
>>> |
|||
|
|||
Use the <package name> package to <list of the main uses for the package>. For example, use <package name> to create/generate/extend/capture <mention major use case, or a good example of what the package can be used for>. The <package name> package also includes <other relevant features or uses>. |
|||
|
|||
> *or* |
|||
|
|||
The <package name> package includes examples of <name of asset type, model, prefabs, and/or other GameObjects in the package>. For more information, see <xref to topic in the Unity Manual>. |
|||
|
|||
>>> |
|||
**_Examples:_** |
|||
|
|||
Here are some examples for reference only. Do not include these in the final documentation file: |
|||
|
|||
*Use the Unity Recorder package to capture and save in-game data. For example, use Unity Recorder to record an mp4 file during a game session. The Unity Recorder package also includes an interface for setting-up and triggering recording sessions.* |
|||
|
|||
*The Timeline Examples package includes examples of Timeline assets, Timeline Instances, animation, GameObjects, and scripts that illustrate how to use Unity's Timeline. For more information, see [ Unity's Timeline](https://docs.unity3d.com/Manual/TimelineSection.html) in the [Unity Manual](https://docs.unity3d.com). For licensing and usage, see Package Licensing.* |
|||
>>> |
|||
|
|||
# Installing <package name> |
|||
>>> |
|||
Begin this section with a cross-reference to the official Unity Manual topic on how to install packages. If the package requires special installation instructions, include these steps in this section. |
|||
>>> |
|||
|
|||
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). |
|||
|
|||
>>> |
|||
For some packages, there may be additional steps to complete the setup. You can add those here. |
|||
>>> |
|||
|
|||
In addition, you need to install the following resources: |
|||
|
|||
- <name of resource>: To install, open *Window > <name of menu item>*. The resource appears <at this location>. |
|||
- <name of sample>: To install, open *Window > <name of menu item>*. The new sample folder appears <at this location>. |
|||
|
|||
|
|||
<a name="UsingPackageName"></a> |
|||
# Using <package name> |
|||
>>> |
|||
The contents of this section depends on the type of package. |
|||
|
|||
For packages that augment the Unity Editor with additional features, this section should include workflow and/or reference documentation: |
|||
|
|||
* At a minimum, this section should include reference documentation that describes the windows, editors, and properties that the package adds to Unity. This reference documentation should include screen grabs (see how to add screens below), a list of settings, an explanation of what each setting does, and the default values of each setting. |
|||
* Ideally, this section should also include a workflow: a list of steps that the user can easily follow that demonstrates how to use the feature. This list of steps should include screen grabs (see how to add screens below) to better describe how to use the feature. |
|||
|
|||
For packages that include sample files, this section may include detailed information on how the user can use these sample files in their projects and scenes. However, workflow diagrams or illustrations could be included if deemed appropriate. |
|||
|
|||
## How to add images |
|||
|
|||
*(This section is for reference. Do not include in the final documentation file)* |
|||
|
|||
If the [Using <package name>](#UsingPackageName) section includes screen grabs or diagrams, a link to the image must be added to this MD file, before or after the paragraph with the instruction or description that references the image. In addition, a caption should be added to the image link that includes the name of the screen or diagram. All images must be PNG files with underscores for spaces. No animated GIFs. |
|||
|
|||
An example is included below: |
|||
|
|||
![A cinematic in the Timeline Editor window.](images/example.png) |
|||
|
|||
Notice that the example screen shot is included in the images folder. All screen grabs and/or diagrams must be added and referenced from the images folder. |
|||
|
|||
For more on the Unity documentation standards for creating and adding screen grabs, see this confluence page: https://confluence.hq.unity3d.com/pages/viewpage.action?pageId=13500715 |
|||
>>> |
|||
|
|||
|
|||
|
|||
# Technical details |
|||
## Requirements |
|||
>>> |
|||
This subtopic includes a bullet list with the compatible versions of Unity. This subtopic may also include additional requirements or recommendations for 3rd party software or hardware. An example includes a dependency on other packages. If you need to include references to non-Unity products, make sure you refer to these products correctly and that all references include the proper trademarks (tm or r) |
|||
>>> |
|||
|
|||
This version of <package name> is compatible with the following versions of the Unity Editor: |
|||
|
|||
* 2018.1 and later (recommended) |
|||
|
|||
To use this package, you must have the following 3rd party products: |
|||
|
|||
* <product name and version with trademark or registered trademark.> |
|||
* <product name and version with trademark or registered trademark.> |
|||
* <product name and version with trademark or registered trademark.> |
|||
|
|||
## Known limitations |
|||
>>> |
|||
This section lists the known limitations with this version of the package. If there are no known limitations, or if the limitations are trivial, exclude this section. An example is provided. |
|||
>>> |
|||
|
|||
<package name> version <package version> includes the following known limitations: |
|||
|
|||
* <brief one-line description of first limitation.> |
|||
* <brief one-line description of second limitation.> |
|||
* <and so on> |
|||
|
|||
>>> |
|||
*Example (For reference. Do not include in the final documentation file):* |
|||
|
|||
The Unity Recorder version 1.0 has the following limitations:* |
|||
|
|||
* The Unity Recorder does not support sound. |
|||
* The Recorder window and Recorder properties are not available in standalone players. |
|||
* MP4 encoding is only available on Windows. |
|||
>>> |
|||
|
|||
## Package contents |
|||
>>> |
|||
This section includes the location of important files you want the user to know about. For example, if this is a sample package containing textures, models, and materials separated by sample group, you may want to provide the folder location of each group. |
|||
>>> |
|||
|
|||
The following table indicates the <describe the breakdown you used here>: |
|||
|
|||
|Location|Description| |
|||
|---|---| |
|||
|`<folder>`|Contains <describe what the folder contains>.| |
|||
|`<file>`|Contains <describe what the file represents or implements>.| |
|||
|
|||
>>> |
|||
*Example (For reference. Do not include in the final documentation file):* |
|||
|
|||
The following table indicates the root folder of each type of sample in this package. Each sample's root folder contains its own Materials, Models, or Textures folders: |
|||
|
|||
|Folder Location|Description| |
|||
|---|---| |
|||
|`WoodenCrate_Orange`|Root folder containing the assets for the orange crates.| |
|||
|`WoodenCrate_Mahogany`|Root folder containing the assets for the mahogany crates.| |
|||
|`WoodenCrate_Shared`|Root folder containing any material assets shared by all crates.| |
|||
>>> |
|||
|
|||
## Document revision history |
|||
>>> |
|||
This section includes the revision history of the document. The revision history tracks when a document is created, edited, and updated. If you create or update a document, you must add a new row describing the revision. The Documentation Team also uses this table to track when a document is edited and its editing level. An example is provided: |
|||
|
|||
|Date|Reason| |
|||
|---|---| |
|||
|Sept 12, 2017|Unedited. Published to package.| |
|||
|Sept 10, 2017|Document updated for package version 1.1.<br>New features: <li>audio support for capturing MP4s.<li>Instructions on saving Recorder prefabs| |
|||
|Sept 5, 2017|Limited edit by Documentation Team. Published to package.| |
|||
|Aug 25, 2017|Document created. Matches package version 1.0.| |
|||
>>> |
|
|||
// -----------------------------------------------------------------------------
|
|||
//
|
|||
// Use this editor example C# file to develop editor (non-runtime) code.
|
|||
//
|
|||
// -----------------------------------------------------------------------------
|
|||
|
|||
namespace UnityEditor.Unity.UIWidgets |
|||
{ |
|||
/// <summary>
|
|||
/// Provide a general description of the public class.
|
|||
/// </summary>
|
|||
/// <remarks>
|
|||
/// Packages require XmlDoc documentation for ALL Package APIs.
|
|||
/// https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/xmldoc/xml-documentation-comments
|
|||
/// </remarks>
|
|||
public class MyPublicEditorExampleClass |
|||
{ |
|||
/// <summary>
|
|||
/// Provide a description of what this private method does.
|
|||
/// </summary>
|
|||
/// <param name="parameter1"> Description of parameter 1 </param>
|
|||
/// <param name="parameter2"> Description of parameter 2 </param>
|
|||
/// <param name="parameter3"> Description of parameter 3 </param>
|
|||
/// <returns> Description of what the function returns </returns>
|
|||
public int CountThingsAndDoStuff(int parameter1, int parameter2, bool parameter3) |
|||
{ |
|||
return parameter3 ? (parameter1 + parameter2) : (parameter1 - parameter2); |
|||
} |
|||
} |
|||
} |
|
|||
fileFormatVersion: 2 |
|||
guid: 064eb42010c5a4828bd610b038b60701 |
|||
MonoImporter: |
|||
externalObjects: {} |
|||
serializedVersion: 2 |
|||
defaultReferences: [] |
|||
executionOrder: 0 |
|||
icon: {instanceID: 0} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
{ |
|||
"name": "Unity.UIWidgets.Editor", |
|||
"references": [ |
|||
"Unity.UIWidgets" |
|||
], |
|||
"includePlatforms": [ |
|||
"Editor" |
|||
], |
|||
"excludePlatforms": [] |
|||
} |
|
|||
fileFormatVersion: 2 |
|||
guid: 1f60b01360afd43e5b5d8c2df6ada626 |
|||
AssemblyDefinitionImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
// -----------------------------------------------------------------------------
|
|||
//
|
|||
// Use this runtime example C# file to develop runtime code.
|
|||
//
|
|||
// -----------------------------------------------------------------------------
|
|||
|
|||
namespace Unity.UIWidgets |
|||
{ |
|||
/// <summary>
|
|||
/// Provide a general description of the public class.
|
|||
/// </summary>
|
|||
/// <remarks>
|
|||
/// Packages require XmlDoc documentation for ALL Package APIs.
|
|||
/// https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/xmldoc/xml-documentation-comments
|
|||
/// </remarks>
|
|||
public class MyPublicRuntimeExampleClass |
|||
{ |
|||
/// <summary>
|
|||
/// Provide a description of what this private method does.
|
|||
/// </summary>
|
|||
/// <param name="parameter1"> Description of parameter 1 </param>
|
|||
/// <param name="parameter2"> Description of parameter 2 </param>
|
|||
/// <param name="parameter3"> Description of parameter 3 </param>
|
|||
/// <returns> Description of what the function returns </returns>
|
|||
public int CountThingsAndDoStuff(int parameter1, int parameter2, bool parameter3) |
|||
{ |
|||
return parameter3 ? (parameter1 + parameter2) : (parameter1 - parameter2); |
|||
} |
|||
} |
|||
} |
|
|||
fileFormatVersion: 2 |
|||
guid: f85dbe0ff914a4c3b9620d093073f3bb |
|||
MonoImporter: |
|||
externalObjects: {} |
|||
serializedVersion: 2 |
|||
defaultReferences: [] |
|||
executionOrder: 0 |
|||
icon: {instanceID: 0} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
{ |
|||
"name": "Unity.UIWidgets", |
|||
"references": [], |
|||
"includePlatforms": [], |
|||
"excludePlatforms": [] |
|||
} |
|
|||
fileFormatVersion: 2 |
|||
guid: 5acfb3d610806475694a55239c7c23f0 |
|||
AssemblyDefinitionImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: 073af4a3d604e42ea849ab8e20463604 |
|||
folderAsset: yes |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
{ |
|||
"displayName":"Example Sample", |
|||
"description": "Replace this string with your own description of the sample. Delete the Samples folder if not needed.", |
|||
"createSeparatePackage": false |
|||
} |
|
|||
// -----------------------------------------------------------------------------
|
|||
//
|
|||
// Use this sample example C# file to develop samples to guide usage of APIs
|
|||
// in your package.
|
|||
//
|
|||
// -----------------------------------------------------------------------------
|
|
|||
fileFormatVersion: 2 |
|||
guid: d0b6d46ec9aeb4883a36de0ed9efc4db |
|||
MonoImporter: |
|||
externalObjects: {} |
|||
serializedVersion: 2 |
|||
defaultReferences: [] |
|||
executionOrder: 0 |
|||
icon: {instanceID: 0} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
{ |
|||
"createSeparatePackage": false |
|||
} |
|
|||
fileFormatVersion: 2 |
|||
guid: 643ff5e7d7c4d44b7b520132441fd8c1 |
|||
folderAsset: yes |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
using UnityEngine; |
|||
using UnityEditor; |
|||
using UnityEngine.TestTools; |
|||
using NUnit.Framework; |
|||
using System.Collections; |
|||
|
|||
class EditorExampleTest { |
|||
|
|||
[Test] |
|||
public void EditorSampleTestSimplePasses() { |
|||
// Use the Assert class to test conditions.
|
|||
} |
|||
|
|||
// A UnityTest behaves like a coroutine in PlayMode
|
|||
// and allows you to yield null to skip a frame in EditMode
|
|||
[UnityTest] |
|||
public IEnumerator EditorSampleTestWithEnumeratorPasses() { |
|||
// Use the Assert class to test conditions.
|
|||
// yield to skip a frame
|
|||
yield return null; |
|||
} |
|||
} |
|
|||
fileFormatVersion: 2 |
|||
guid: 324dcc98993604886878344a0ea94d18 |
|||
MonoImporter: |
|||
externalObjects: {} |
|||
serializedVersion: 2 |
|||
defaultReferences: [] |
|||
executionOrder: 0 |
|||
icon: {instanceID: 0} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
{ |
|||
"name": "Unity.UIWidgets.Editor.EditorTests", |
|||
"references": [ |
|||
"Unity.UIWidgets.Editor", |
|||
"Unity.UIWidgets" |
|||
], |
|||
"optionalUnityReferences": [ |
|||
"TestAssemblies" |
|||
], |
|||
"includePlatforms": [ |
|||
"Editor" |
|||
], |
|||
"excludePlatforms": [] |
|||
} |
|
|||
fileFormatVersion: 2 |
|||
guid: ddfee6fb567544c4d81e78d84f47d64c |
|||
AssemblyDefinitionImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
fileFormatVersion: 2 |
|||
guid: c2d6e16ea80ac4c7c83c21d2d0d9a4ee |
|||
folderAsset: yes |
|||
DefaultImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
using UnityEngine; |
|||
using UnityEngine.TestTools; |
|||
using NUnit.Framework; |
|||
using System.Collections; |
|||
|
|||
class RuntimeExampleTest { |
|||
|
|||
[Test] |
|||
public void PlayModeSampleTestSimplePasses() { |
|||
// Use the Assert class to test conditions.
|
|||
} |
|||
|
|||
// A UnityTest behaves like a coroutine in PlayMode
|
|||
// and allows you to yield null to skip a frame in EditMode
|
|||
[UnityTest] |
|||
public IEnumerator PlayModeSampleTestWithEnumeratorPasses() { |
|||
// Use the Assert class to test conditions.
|
|||
// yield to skip a frame
|
|||
yield return null; |
|||
} |
|||
} |
|
|||
fileFormatVersion: 2 |
|||
guid: 59b1c9d60b19a408898d5495008de48e |
|||
MonoImporter: |
|||
externalObjects: {} |
|||
serializedVersion: 2 |
|||
defaultReferences: [] |
|||
executionOrder: 0 |
|||
icon: {instanceID: 0} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
|
|||
{ |
|||
"name": "Unity.UIWidgets.Tests", |
|||
"references": [ |
|||
"Unity.UIWidgets" |
|||
], |
|||
"optionalUnityReferences": [ |
|||
"TestAssemblies" |
|||
], |
|||
"includePlatforms": [], |
|||
"excludePlatforms": [] |
|||
} |
|
|||
fileFormatVersion: 2 |
|||
guid: 14a815924271b4a9f9efdffaba3f607b |
|||
AssemblyDefinitionImporter: |
|||
externalObjects: {} |
|||
userData: |
|||
assetBundleName: |
|||
assetBundleVariant: |
撰写
预览
正在加载...
取消
保存
Reference in new issue