A package on asterobot.net changes by getting new versions on the same file. The people who installed it see the update the next time they check for updates, and choose when to move their bots to it.
Prepare the new version
- In Library Manager, open your package's menu and choose Copy to a new version, with a higher version such as
1.0.1or1.1.0. Names and versions says which number to raise. - Make your changes in the copy, and test it on your bots.
- Check what your changes do to the settings people saved: a renamed setting loses its values, and a new default doesn't reach the bots that already saved one. See Read settings.
- Go through Before you publish again.
- Export the new version, which gives a file such as
my-bot-1.0.1.zip.
Upload it to the same file
On your file's page on asterobot.net, upload a new version of the file:
- Replace the attachment with the new
.zip, so the file still has exactly one attachment. - Set the file's version to the new version, written exactly as in your library.
- Say what changed, especially anything people have to do, such as checking a setting.
- Keep the title, since a new title gives new users a different package name: see How your package is named.
Always update the existing file, never submit a new one for a new version. Asterobot checks for updates against the file a package was installed from, so people who have your package never see a new file as an update. And since a package's name comes from its author and title, a second file with the same title installs under the same name as the first, which only adds confusion.
How people get the update
Nothing changes on anyone's Asterobot by itself. When someone clicks Check for updates in Library Manager, Asterobot compares each package they installed from the marketplace with the current version of its file:
| The file's current version is | They see |
|---|---|
| Higher than theirs, both being semantic versions | Update to followed by the version |
| Lower than theirs | Nothing: Asterobot never offers to go back |
| The same as theirs | Nothing |
| Different, when either version isn't a semantic version | Update to, even for an older version |
Update to installs the new version next to the old one. Their bots stay on the old version until they move them, one by one, and keep the settings they saved. The old version stays until they remove it. Update packages describes their side. Packages that were installed as dependencies of another package are checked the same way.
Packages that depend on yours
A package that depends on yours locks one exact version of it. Which version it gets depends on what its author declared, at the moment someone installs that package:
| The dependency's version | The version installed |
|---|---|
An exact version, such as 1.0.0 |
That version: your file's current version when it's the same, otherwise the same version from your file's history |
A range, such as ^1.0.0 |
The highest matching version, among your file's current version and its history |
latest |
Your file's current version |
Afterwards, the installed package keeps the version it got. Your update doesn't change it, even when the same person installs your new version with Update to. It moves to a newer version of yours when its author publishes an update of their own package, or when someone installs that package again and its declaration picks your newer version.
Keep older versions available
Asterobot fetches an older version of your package from your file's version history on asterobot.net. A package that locks your 1.0.0, while your file's current version is 1.1.0, can only be installed as long as 1.0.0 is still in that history. When it isn't, installing that package fails. So keep your previous versions in the file's history for as long as other packages may lock them.
Never reuse a version number
Once a version is published, never publish different code under the same number, not even to fix a mistake a minute later. Asterobot tells versions apart by their number alone:
- People who already installed that version aren't offered the new code, since Check for updates sees the same version. They only get it if they happen to install that version again.
- People who install it afterwards get the new code under the same number. Two people with
1.0.1then run different code, and nobody can tell from the version which one they have. - The same goes for packages that lock that exact version: installed before, they keep the old code, installed after, they get the new one.
- Asterobot can't notice it. It records a checksum of a package's files when it installs the package from the marketplace, and refuses the package if those files change on that computer afterwards. That protects what was downloaded, but the checksum comes from the download itself, so it can't tell that the file on asterobot.net changed.
Publish the fix as a new version, such as 1.0.2, instead. That one reaches everyone through Check for updates.
When a version goes wrong
If you publish a broken version, don't set the file back to an older version number: the people who installed the broken one wouldn't be offered the older one, since Asterobot never offers to go back. Publish a fixed version with a higher number, and say in the description which version to avoid.
Next, How your package is named.
Aucun avis à afficher.