Updating#
Publishing an improvement uses the same upload action as the original package. The [Version] attribute determines whether users see an update and whether the Registry replaces the existing release in place.
Shipping an update#
- Change the code.
- Increment
[Version(major, minor, patch)]. - Right-click the file and choose
Visual Script→Upload to Registry.
The dialog confirms Package has been successfully updated, and the listing shows the new version and a NEW badge. The version you upload determines how the Registry treats the release:
| You upload with | Result |
|---|---|
| A higher version | The listing is updated. Everyone who installed it sees an Update button. |
| The same version | The listing is replaced in place. Use this only for metadata corrections because users don't see an update. |
| A lower version | The listing moves backward. Users who already have a newer version don't see an Update button. |
Users choose when to update
Visual Script doesn't send update notifications. It compares the installed file's [Version] with the published version and displays Update in the Registry inspector when the installed version is older. The user chooses when to replace the file.
Choosing a version number#
Use the version number to communicate compatibility with existing scenes and prefabs:
| Increment | Use when |
|---|---|
Patch — 1.0.0 → 1.0.1 |
You fix a bug while preserving intended behavior. |
Minor — 1.0.1 → 1.1.0 |
You add behavior while keeping existing usage working. |
Major — 1.1.0 → 2.0.0 |
A change that breaks existing usage. |
Avoid a major update when you can preserve serialized data and existing behavior. When a breaking change is necessary, describe the required migration in [Description] or [Note], such as 2.0 renames the Amount field; reassign it after updating.
Changing a published type can lose saved values
Visual Script stores nodes by their assembly-qualified type name. Renaming the class, changing its namespace, or moving it to another assembly orphans every existing reference.
The node then returns as null in each scene and prefab that used it, and its configured values are lost.
Renaming a field, removing a parameter, or changing its meaning can also invalidate serialized data. If a rename is unavoidable, use Unity's [MovedFrom] attribute to preserve the mapping. See Conventions.
Maintaining a package#
- Keep the description accurate. Update the description and keywords when the node's behavior changes.
- Keep dependencies current. Add
[Dependency]in the same upload when a new version requires another package or asset. - Watch the Broken badge. Repeated reports can flag the listing after a Unity version or dependency change breaks the package.
- Provide a support location.
[Documentation("url")]adds a Docs button that can point to a page, repository, or support thread.
When you're done maintaining it#
Add a [Note] when the package is no longer maintained, including the last version you verified. Developers can then evaluate the source and decide whether to keep using it.
To remove the package, open its page on visualscript.dev and press Delete.
Deleting removes the Registry download
Deleting removes the listing and its download. Installed copies remain in existing projects, but new users can't install the package and every list containing it loses that member.
If the last release still works, prefer an unmaintained [Note] so the download remains available with an explicit maintenance status.
Where to go next#
- Publishing — follow the complete upload flow.
- Contributing — prepare a package for other developers.
- Lists — group related packages for discovery and installation.