How to Best Keep Distinct Package Editions

Tooling Package Management
1

I have a package which reproduces equations from a professional standard that is revised every two years. I need to be able to access specific editions of the package which are linked to specific editions of the standard document e.g. 2025 Edition. What is the best way to smoothly achieve that?

I used to make a new package with the year in the package name, but that was a lot of work, and realistically, the content of the standard doesn’t change much, if at all, between editions. I’m currently considering two new options (but am open to others).

  1. Keep persistent git branches e.g. 2025.
  2. Hijack the release version number to use year as the “major” digit e.g. 2025.0.0.

Which method do you think would cause the least friction for my internal users?
(I intend to register this package with LocalRegistry.jl using a local file server for others in my company, but I am still setting that up.)

2

If you change the major version it will be impossible to load both versions in the same Julia process.

If most of the standard doesn’t change you can keep the same package but version the functions and constants inside the package. Like

foo2023(a, b, c) = a + b + c

const foo2025 = foo2023
3

I think the best approach is to create a single package where each version is a module (aka Version.jl). You move all the commonalities into a single top module, then have dedicated sub modules for the version specific details. That also makes it really clear to users what changes from one to the next version. It also avoids clashing definitions and gives you a clear namespace for each specific version.

4

That has nothing to do with major versions. You can only load one version of a given package in the same process, no matter in what way the version numbers differ.

5

I will typically not need to access multiple Editions in the same Julia process. They would be used in separate analyses.

6

I don’t think I like this idea because it forces me to change all my downstream function calls in the packages using this package e.g. from Div3.2023.KM6.f(x) to Div3.2025.KM6.f(x). I would rather load a specific version of Div3.jl into an environment and have the function definitions update in place when called by a downstream package there e.g. as Div3.KM6.f(x). I have tried to reproduce the source text as closely as possible, giving the equations the same names in the same order, so I am reluctant to scramble them into different common or edition-specific modules.

7

No it doesn’t. Because you can just do

julia> module A

       module B

           f(x) = x^2

       end

       module C

           f(x) = x^3

       end

       end
Main.A

julia> using .A.B: f

julia> f(2)
4

You want to switch versions for an entire package, you just do

julia> using .A.C: f

julia> f(2)
8
8

See the approach in PhysicalConstants.jl. They use different modules for CODATA2014, CODATA2018 and CODATA2022 .

9

As a variation of @langestefan’s answer, you could say

import Div3.v2023 as Div3

at the beginning of your file (if the version is called v2023) and then later simply Div3.KM6.f(x).