You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The version is automatically generated whenever the projects are built, using the [Nerdbank.GitVersionining](https://github.com/aarnott/Nerdbank.GitVersioning) package. This package generates semver versions based on the version set in the `version.json` file at the root of the repo + the commit height since the last time the version was updated.
10
+
11
+
Not all changes affect the commit height/version update. Only changes in the paths tracked by the `src/version.json` file cause version updates.
12
+
13
+
By default, only builds from branches/tags that match the regex in the [version.json](version.json) file at the root of the repo will be stamped with a public release (semantic) version, and other builds will be preview builds.
14
+
15
+
- C#/nuget public version format: `X.Y.[commit height]`.
16
+
- C#/nuget non-public version format: `X.Y.[commit height]-g[commit hash]`.
17
+
- Packman public version format: `X.Y.[commit height]`.
18
+
- Packman non-public version format: `X.Y.[commit height]`-preview-g[commit hash].
19
+
20
+
If the fixed part of the version in the `version.json` file is a semver preview version (i.e. it contains a `-alphanumeric` suffix), then the versioning is as follows:
21
+
22
+
- C#/nuget public version format: `X.Y.[commit height]-alphanumeric`.
23
+
- C#/nuget non-public version format: `X.Y.[commit height]-alphanumeric-g[commit hash]`.
24
+
- Packman public version format: `X.Y.[commit height]-preview-alphanumeric`.
25
+
- Packman non-public version format: `X.Y.[commit height]`-preview-alphanumeric-g[commit hash].
26
+
27
+
## Command line build scripts
28
+
29
+
-`build.cmd`/`build.sh`: Build shell script for Windows command line or Windows/Mac/Linux bash.
30
+
-`pack.cmd`/`pack.sh`: Packaging shell script for Windows command line or Windows/Mac/Linux bash.
31
+
-`test.cmd`/`test.sh`: Test shell script for Windows command line or Windows/Mac/Linux bash.
32
+
33
+
All shell scripts take the same parameters:
34
+
35
+
-`-r|--release`: Release build (default)
36
+
-`-d|--debug`: Release build (default)
37
+
-`-p|--public`: Stamp a build with a public release version. See the [versioning](#versioning) section for details
38
+
39
+
### Visual Studio
40
+
41
+
To build with Visual Studio, open the solution file `GitForUnity.sln`. Select `Build Solution` in the `Build` menu.
42
+
43
+
## Build artifacts
44
+
45
+
Before opening the Unity projects in the `UnityProjects` folder, you should build at least once, so that required binaries are generated in the right places.
46
+
47
+
Note: If you build while having a Unity project open that points to the sources or build artifacts, some files might be locked by Unity if have one of the build output projects open when you compile from VS or the command line. This is expected and shouldn't cause issues with your builds.
48
+
49
+
### Packman (npm) sources
50
+
51
+
The sources and tests for each package are versioned and copied to `build/packages` as part of the build process. Metafiles for autogenerated build artifacts (like the `Version.cs` file generated during the build) are copied from the `extras/[name of package]` folder into `build/packages`.
52
+
The artifacts in `build/packages` are used for packaging during the `pack` step.
53
+
54
+
## Packaging
55
+
56
+
### Windows
57
+
58
+
- Release build packaging: `.\pack`
59
+
- Debug build packaging: `.\pack -d`
60
+
- Build and pack in one: `.\pack -b`
61
+
62
+
### Mac, Linux, Windows Bash
63
+
64
+
- Release build packaging: `./pack.sh`
65
+
- Debug build packaging: `./pack.sh -d`
66
+
- Build and pack in one: `./pack.sh -b`
67
+
68
+
## Packaging artifacts
69
+
70
+
### Packman (npm)
71
+
72
+
- Location: `upm-ci~/packages`
73
+
74
+
### Nuget
75
+
76
+
- Location: `build/nuget`
77
+
78
+
## Testing
79
+
80
+
### Windows
81
+
82
+
- Test release: `.\test`
83
+
- Test debug: `.\test -d`
84
+
- Build and test: `.\test -b`
85
+
86
+
### Mac, Linux, Windows Bash
87
+
88
+
- Test release: `./test.sh`
89
+
- Test debug: `./test.sh -d`
90
+
- Build and test: `./test.sh -b`
91
+
92
+
## Where are the build artifacts?
93
+
94
+
Packages sources are in `build/packages`.
95
+
96
+
Nuget packages are in `build/nuget`.
97
+
98
+
Packman (npm) packages are in `upm-ci~/packages`.
99
+
100
+
Binaries for each project are in `build/bin` for the main projects, `build/Samples/bin` for the samples, and `build/bin/tests` for the tests.
101
+
102
+
## How to bump the major or minor parts of the version
103
+
104
+
The `version.json` file in the root of the repo controls the version for all packages.
105
+
Set the major and/or minor number in it and **commit the change** so that the next build uses the new version.
106
+
The patch part of the version is the height of the commit tree since the last manual change of the `version.json`
107
+
file, so once you commit a change to the major or minor parts, the patch will reset back to 0.
Copy file name to clipboardExpand all lines: README.md
+56-20Lines changed: 56 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,13 +13,13 @@ It's been split up for easier testing and consumption by the Git package and any
13
13
- UI: tasks can be scheduled to the UI thread, which uses `EditorApplication.delayCall`
14
14
15
15
- Exclusive/Concurrent: A pair of synchronized schedulers allow for a one writer/many readers scenario, where any task with an Exclusive affinity is guaranteed to run on its own without any other Exclusive or Concurrent affinity tasks executing at the same time. Concurrent affinity tasks can run with other tasks any affinity except Exclusive.
16
-
17
-
This allows tasks to safely execute code that requires locking resources without worrying about other threads touching the same resources.
16
+
17
+
This allows tasks to safely execute code that requires locking resources without worrying about other threads touching the same resources.
18
18
19
19
- None: tasks run on the default scheduler (threadpool) without constraints.
20
20
- LongRunning: tasks run on the default scheduler (threadpool), but the task management system doesn't expect them to finish in a short time and doesn't impose task timeouts (if the task supports such a thing);
21
21
22
-
It provides easy chaining of tasks with a rx.net-like API that allows data flow from one task to the other, progress reporting, catch and finally handlers, support for wrapping async/await methods and for ensuring they run outside of play mode, and ready-made tasks for running processes and processing/streaming their output.
22
+
It provides easy chaining of tasks with a linq-style API that allows data flow from one task to the other, progress reporting, catch and finally handlers, support for wrapping async/await methods and for ensuring they run outside of play mode, and ready-made tasks for running processes and processing/streaming their output.
23
23
24
24
Standard .NET async methods can be integrated into this library and executed with specific affinities using the `TPLTask` class. Similarly, going from an Editor Task to the async/await model is just a matter of awaiting the underlying `Task` property.
// finally handlers will always be called. Always end a chain with a Finally* handler!
79
-
.FinallyInUI((success, exception, value) => {
80
-
EditorUtility.ClearProgressBar();
78
+
// finally handlers will always be called. Always end a chain with a Finally* handler!
79
+
.FinallyInUI((success, exception, value) => {
80
+
EditorUtility.ClearProgressBar();
81
81
82
-
if (success) {
83
-
// do something on success
84
-
EditorUtility.DisplayDialog("All done", value);
85
-
} else {
86
-
Debug.LogException(exception);
87
-
}
88
-
});
82
+
if (success) {
83
+
// do something on success
84
+
EditorUtility.DisplayDialog("All done", value);
85
+
} else {
86
+
Debug.LogException(exception);
87
+
}
88
+
});
89
89
90
90
// start executing the whole thing
91
91
chainOfTasks.Start();
@@ -100,6 +100,42 @@ The next best thing was to code modern .NET and use a version of the TPL library
100
100
101
101
These days, Unity supports modern .NET and can compile all this code just fine, so this library no longer ships with .NET 3.5 support, but it still maintains its separation from Unity - the projects don't reference Unity, and any Unity integration code in this library is behind a `#if UNITY_EDITOR` define, so you can safely consume the nuget packages in any .NET environment, and Unity-specific functionality will only be available when you consume this library as a package in a Unity project.
102
102
103
+
104
+
## How to build
105
+
106
+
Check [How to Build](https://raw.githubusercontent.com/Unity-Technologies/Git-for-Unity/master/BUILD.md) for all the build, packaging and versioning details.
107
+
108
+
### Release build
109
+
110
+
`build[.sh|cmd] -r`
111
+
112
+
### Release build and package
113
+
114
+
`pack[.sh|cmd] -r -b`
115
+
116
+
### Release build and test
117
+
118
+
`test[.sh|cmd] -r -b`
119
+
120
+
121
+
### Where are the build artifacts?
122
+
123
+
Packages sources are in `build/packages`.
124
+
125
+
Nuget packages are in `build/nuget`.
126
+
127
+
Packman (npm) packages are in `upm-ci~/packages`.
128
+
129
+
Binaries for each project are in `build/bin` for the main projects and `build/tests` for the tests.
130
+
131
+
### How to bump the major or minor parts of the version
132
+
133
+
The `version.json` file in the root of the repo controls the version for all packages.
134
+
Set the major and/or minor number in it and **commit the change** so that the next build uses the new version.
135
+
The patch part of the version is the height of the commit tree since the last manual change of the `version.json`
136
+
file, so once you commit a change to the major or minor parts, the patch will reset back to 0.
0 commit comments