In order for packages to be automatically merged into the general registry, it is required that the package’s
Project.toml contains a
compat section giving upper version bounds on all direct dependencies.
I wanted to bring a few concerns to the forefront of the minds of package developers, so that we don’t inadvertently get burned by this practice:
Don’t tag your new version as containing breaking changes unless it really does
≥ v"1.0", any time there are version differences of at least
v"1.0" it implies there are breaking changes. For versions
< v"1.0", any time there are version differences of at least “v"0.1” it implies there are breaking changes. In the Julia ecosystem, the overwhelming majority of packages have versions
< v"1.0". I know it is tempting to bump the middle version number if there is some significant internal change. It seems to me that this indeed happens sometimes, and I’m probalby guilty of this myself. If you do this, every package that depends on yours will stop using your latest tags by default, so you should only bump this number if it really is necessary because of some breaking change to the external API of your package.
When incrementing the version number, consider testing packages that use yours as a dependency
It is frequently the case that an author makes breaking changes, but that these are minimal and there’s a good chance that some packages won’t break. Again, if you change the version to indicate a breaking change, initially not much will actually use it by default. If you want people to actually use your new tag, it might require you to test some packages you may be aware of that use your package. Authors of other packages probably aren’t going to be overly aware of your version history, so you’ll be helping them out if you can check whether your package still works. Of course, I’m not suggesting that packages that depend on one’s package are the responsibility of that package’s author, but there will be many cases in which that author is aware of some of the major use cases. This sort of practice is a good complement to internal unit tests anyway.
Consider having a clear separation between unit tests of the external API and those of package internals
The former can be used to assess breakage.
check your package’s
compat section (at least) every time you tag a release
This is probably the most important point. If you forget about this, your package will be stuck downgrading everything to old packages forever. When developing your code, I strongly recommend commenting out the
compat section entirely so that you are running on all the latest releases. Then, when it comes time to tag a release, you can check what versions of everything is getting used and put them in.
I think everything I said here is pretty uncontroversial, I’m sure I’ll hear about it if I’m wrong.