Solution.Common

Solution.Common is the shared Unity foundation used across SolutionWCMD projects and packages.

Originally extracted from the Solution game project, it provides reusable utilities, architectural patterns, and Unity-specific helpers for building maintainable gameplay systems, tools, and services. It can be used as a dependency of other SolutionWCMD packages or installed independently in any compatible Unity project.

• Package ID: com.solution.common
• Current stable API line: 1.x
• Unity target: 6000.0.24f1
• License: MIT

The package is organized into focused namespaces:

The full documentation contains more detailed explanations and usage examples.

The package manifest currently targets:

Unity 6000.0.24f1

Earlier Unity versions are not supported by the current package manifest. Compatibility with newer Unity versions should still be validated in the consuming project before deployment.

Install Solution.Common through Unity Package Manager using a Git URL.

1. Open Window > Package Manager in Unity.
2. Select the + button.
3. Select Add package from git URL...
4. Paste the following URL:

https://github.com/Solution-WCMD/SolutionWCMD-Common.git?path=/Assets/SCommon#v1.0.0

5. Replace v1.0.0 with the exact release tag you want to use.
6. Select Add.

The ?path=/Assets/SCommon parameter is required because the Unity package manifest is located inside that directory rather than at the repository root.

You can also add the package directly to the dependencies object in your Unity project's Packages/manifest.json:

"com.solution.common": "https://github.com/Solution-WCMD/SolutionWCMD-Common.git?path=/Assets/SCommon#v1.0.0"

Replace v1.0.0 with the release tag selected for your project.

Available stable versions can be found on the Releases page.

Solution.Common uses Semantic Versioning for stable releases:

MAJOR.MINOR.PATCH

The type of version change indicates whether an upgrade is expected to require changes in the consuming application.

Patch and minor releases within the same major version are intended to remain source-compatible. They should not require consumers to rename types, replace APIs, or redesign integrations.

However, every dependency update can still affect runtime behavior. Projects should therefore validate compilation, tests, scenes, prefabs, serialization, editor tooling, and production builds before accepting an update.

2.0.0 will intentionally break parts of the existing 1.x API.

Applications currently using 1.x should not automatically upgrade merely because 2.0.0 is newer. This includes applications that are still new, unreleased, or under active development. Once an application depends on the 1.x API, moving to 2.0.0 must be treated as a migration rather than a routine package update.

Remain pinned to an exact 1.x release unless the project is prepared to:

1. Review the 2.0.0 release notes and migration requirements.
2. Identify every affected Solution.Common integration.
3. Update application code and dependent packages.
4. Resolve compilation and serialization changes.
5. Retest editor workflows, runtime behavior, and production builds.
6. Complete the migration on an isolated branch before merging it into the main application codebase.

Do not change a dependency URL from a 1.x tag to v2.0.0 until those steps can be completed.

Use the following policy when choosing a dependency version:

To update between stable versions:

1. Read the relevant changelog and release notes.
2. Create a dedicated update branch in the consuming project.
3. Commit the existing Packages/manifest.json and Packages/packages-lock.json.
4. Change only the version tag after # in the Git URL.
5. Allow Unity Package Manager to resolve the updated dependency.
6. Confirm that the project compiles without new warnings or errors.
7. Run applicable Edit Mode and Play Mode tests.
8. Open and validate scenes, prefabs, ScriptableObjects, and editor tools that use the package.
9. Produce and validate at least one representative application build.

Major-version upgrades require the additional migration work described in the release notes.

The primary API documentation is available here:

• Solution.Common documentation
• Changelog
• GitHub releases

The documentation focuses on the package's commonly used public systems. Internal helpers and specialized low-level implementations may not be documented individually.

External contributions are welcome when they improve the existing package without expanding its independently managed feature scope.

Suitable contributions include:

• Bug fixes that preserve the compatibility policy of the current major version.
• Small maintainability improvements.
• Corrections and improvements to existing documentation.
• Focused fixes for clearly reproducible problems.

The following contribution rules apply:

• Pull requests must target the development branch.
• Pull requests targeting release, live, or another protected delivery branch may be closed without review.
• New features, new public systems, and new classes are reserved for the SolutionWCMD development roadmap and are generally not accepted through unsolicited pull requests.
• Pull request titles must clearly describe the change.
• Pull request descriptions must explain the problem, reasoning, scope, and validation performed.
• Changes should remain focused and avoid unrelated refactoring.
• Contributions outside the supported scope may be closed without review.

Before opening a pull request, verify that the project compiles and that the proposed change does not unintentionally break existing consumers.

This package may include or depend on third-party software.

See Third Party Notices for attribution and licensing information.

Solution.Common is available under the MIT License.

See LICENSE for the complete license text.