Skip to content

chore: editor namespace auto upgrade - #4142

Open
NoelStephensUnity wants to merge 6 commits into
develop-3.x.xfrom
chore/editor-namespace-auto-upgrade
Open

chore: editor namespace auto upgrade#4142
NoelStephensUnity wants to merge 6 commits into
develop-3.x.xfrom
chore/editor-namespace-auto-upgrade

Conversation

@NoelStephensUnity

Copy link
Copy Markdown
Member

Purpose of this PR

This PR handles the auto-upgrade namespace change from Unity.Netcode.Editor to Unity.Netcode.GameObjects.Editor.
It also includes a job that can be manually triggered to validate the auto-upgrade or the job itself could be added to nightly or the like.

Jira ticket

MTT-15570

Changelog

NA

Documentation

  • No documentation changes or additions were necessary.

Testing & QA (How your changes can be verified during release Playtest)

Functional Testing

Manual testing :

  • Manual testing done

Automated tests:

  • Covered by existing automated tests
  • Covered by new automated test

Does the change require QA team to:

  • Review automated tests?
    • Currently, it is only wired into the comment trigger ("apiupdater").
    • @michalChrobot Feel free to adjust this if you want it to automatically run under specific conditions.
  • Execute manual tests?
  • Provide feedback about the PR?

If any boxes above are checked the QA team will be automatically added as a PR reviewer.

Up-port

None

Backports

None

marking all unity.netcode.editor public API as having moved to a new namespace in order to auto-upgrade users.
Adding a project verification test that can be triggered by typing "apiupdater" as a comment.
The project added verifies that the entire public API within the unity.netcode.editor namespace is auto-upgraded without compilation errors.
@NoelStephensUnity
NoelStephensUnity requested review from a team and EmandM as code owners August 24, 2026 20:29

@u-pr u-pr Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Harness Review

Needs changes

The relocation metadata covers the unconditional public editor API, but the new validation harness has a configuration-specific coverage gap and cannot be run reliably from paths containing spaces.

Reviewed commit dcf9a26

🤖 Helpful? 👍/👎

)

Write-Host 'Running the editor (this imports the project and runs the API updater)...'
$process = Start-Process -FilePath $unity -ArgumentList $unityArgs -PassThru -Wait -NoNewWindow

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1

Start-Process joins this array into one command line without preserving quotes around individual values. If the checkout is under a path such as C:\Users\Jane Doe\src, both $projectPath and $logFile are split at the space, so Unity receives an invalid -projectPath/-logFile and the documented local test cannot run. Quote/escape those two values when building the argument string, or use ProcessStartInfo.ArgumentList to pass them as distinct arguments.

🤖 Helpful? 👍/👎

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@u-pr This is fixed and should no longer be a problem.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Quoting "$projectPath" and "$logFile" ensures the paths won't be split on spaces when passed to Start-Process.

🤖 Helpful? 👍/👎

# Every 2.x type the sources reference, and what the updater is expected to turn it into.
# Frozen: this is the public editor API of develop-2.0.0, which is released and will not change.
# Extend it by hand if a public editor type is ever relocated again within 3.x.
$expected = @(

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2

This expected list has no NetworkObjectOwnership entry, and the fixture never references it. That class is a public old editor type whenever BYPASS_DEFAULT_ENUM_DRAWER && MULTIPLAYER_SERVICES_SDK_INSTALLED is enabled, so the test currently cannot verify the [MovedFrom] just added for that supported compilation mode; a regression there will still report success. Add a fixture/configuration that enables those symbols and include the type in the expected results.

🤖 Helpful? 👍/👎

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@u-pr Can you re-verify this? I remove that legacy script in NetworkObjectEditor.cs so it should not be of concern now.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verified. Since NetworkObjectOwnership has been removed from NetworkObjectEditor.cs rather than migrated to the new namespace with a [MovedFrom] attribute, it no longer needs coverage in DeprecatedApiUsage.cs or the $expected list in run-upgrade-test.ps1. The concern is resolved.

🤖 Helpful? 👍/👎

Removed obsolete custom property drawer for NetworkObject.OwnershipStatus.
Handling paths with spaces.
Remove this too as we don't need that work around.
@@ -0,0 +1,78 @@
# This .gitignore file should be placed at the root of your Unity project directory

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need this?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It helps keep it clean from "noise changes".
It is the same as the testproject one.

@@ -0,0 +1,173 @@
<#

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a powershell script so it can't be run from Ubuntu or MacOS. It's also pretty opaque claude written code. A python script (@michalChrobot already has a few python scripts) would probably be preferred. Not a blocker, just a concern

@NoelStephensUnity NoelStephensUnity Aug 24, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can make that something more generic.

@@ -0,0 +1,121 @@
# API updater upgrade-path project

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This README has too much info. The README from this project doesn't need info on how the upgrade was implemented, it just needs info on how it works.

If you want this project to be used also for future upgrades then this README shouldn't have any references to the 2.x -> 3.x upgrade specifically, otherwise future us might think we can pull this project out once that upgrade is released.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This project and the tests associated with it will not be pertinent once v2.x.x becomes deprecated.
But I can remove the extra info...leaving it only provides the context as to why it is there in the first place.

{
"disableProjectUpdate": false,
"dependencies": {
"com.unity.netcode.gameobjects": "file:../../com.unity.netcode.gameobjects",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be nice to have N4E in here so we can be sure the upgrade doesn't introduce a conflict with N4E

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was tested extensively locally. Nothing wrapped in UNIFIED_NETCODE is impacted by the namespace migration since anything that does reference NGO editor classes(etc) already has the change applied and no user has any script that could cause conflicts.

This validates without N4E an NGO users upgrading from v2.x to v3.x will automatically have everything that needs to be updated...updated.

@codecov-github-com

codecov-github-com Bot commented Aug 24, 2026

Copy link
Copy Markdown

Codecov Report

All modified and coverable lines are covered by tests ✅

@@              Coverage Diff               @@
##           develop-3.x.x    #4142   +/-   ##
==============================================
  Coverage          78.00%   78.00%           
==============================================
  Files                153      153           
  Lines              26260    26260           
==============================================
  Hits               20483    20483           
  Misses              5777     5777           
Flag Coverage Δ
NGOv2_project_testproject_ubuntu_pinnedTrunk 77.58% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components Coverage Δ
com.unity.netcode.gameobjects 78.00% <ø> (ø)

ℹ️ Need help interpreting these results?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants