# 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

1. Change the code.
2. Increment `[Version(major, minor, patch)]`.
3. 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. |

!!! info "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*.

!!! danger "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](../scripting-api/conventions.md#serialization).

## 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](https://visualscript.dev) and press **Delete**.

!!! warning "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](publishing.md)** — follow the complete upload flow.
- **[Contributing](contributing.md)** — prepare a package for other developers.
- **[Lists](lists.md)** — group related packages for discovery and installation.