How to manage versions in my package?

General Usage
,
1

I am writing my own package, and I want to implement versions.
I am using this package in my projects, and I want to make sure that old projects can use an old version of the package while new projects can use the new version. Is there a way to properly maintain versions?

2

Sure! Julia’s package versioning system is great for that. If you maintain the package as a git repository, each commit is a potential different version, which users can choose at their will for each project:
https://pkgdocs.julialang.org/v1/managing-packages/

The “proper way” of maintaining versions, however, also involves registering your package (you can use the General registry, or even make your own local registry), so that you can tell the package manager what version you want to add using version numbers, instead of ugly git commit IDs.

Each new version that you register, takes its number from the Project.toml file:
https://pkgdocs.julialang.org/v1/toml-files/

2 Likes
3

It is not necessary to register a package. Versions are available by referring to tags
of unregistered packages. One can do ]add https:...PackageName.git#v1.5.1 using tags. Here v1.5.1.

2 Likes
4

Oh yes, you’re right!

Just for clarity, then I think it’s advisable to distinguish between “registered versions” (those that you can add as ]add PackageName@1.5.1 and “tagged versions” (]add PackagePath#v1.5.1). Julia’s TagBot helps to keep both kinds of versions sync’ed in registered packages, but same numbers of those two kinds of versions might refer to different commits!

2 Likes
5

@PetrKryslUCSD @heliosdrm Thank you very much for the useful answers.
At the moment I am still in the phase of developing the package, so I am using dev Package when I use it in my projects since I am changing things all the time.
So it seems to me like versioning should work only with add Package, which means it is not suited for my case really. Perhaps I am not in the phase of versioning yet.

6

Yes, when the package is installed in an environment as dev, no fixed version is used: using Package just looks into the local version of the code – including changes you make to it.

Nevertheless, you can have a package in perpetual dev state, and yet (if you are using git for version control) register or tag particular commits, so that in some projects with their own environment, you add those fixed versions in a reproducible way, as indicated. That’s possible even on the same computer.

3 Likes