Include new test Project file logic also into 1.0?

Hi, I just stumbled upon the switch in the recommendation about where to configure test dependencies.

https://julialang.github.io/Pkg.jl/v1/creating-packages/#Test-specific-dependencies-in-Julia-1.2-and-above-1

Apparently, when you want to support 1.0, you still have to use the old approach. And as the old approach still works in newer languages, it hence seems to be the recommended approach to stick to the old. That is a pity, as I really appreciate the new setup with a new Project file under the test directory.

From my perspective it seems like adding the support for the project file to 1.0 is possible in principle, as this does not break existing supported setups. Of course if someone used a test/Project.toml for something unrelated that would break, but I think that is not a big issue as it was not supported anyway.

Hence I would argue for including the test/Project.toml support in the next 1.0.X release.
This would enable everyone to use the new format without dropping support on 1.0 or having to maintain two locations of test-dependencies. Hence it could truly become the new recommended approach.

What are you thoughts?

1 Like

Technically I think that adding functionality like this requires a minor version bump, so it cannot be a 1.0.x version.

Also, I am not sure how it wouold help your use case. You still couldn’t claim that you “support 1.0”, because that would require supporting 1.0.y for any y, including y < x.

3 Likes

Note the:

The exact interaction between Project.toml , test/Project.toml and their corresponding Manifest.toml s are not fully worked out, and may be subject to change in future versions. The old method of adding test-specific dependencies, described in the next section, will therefore be supported throughout all Julia 1.X releases.

Features are not backported. If you need to support LTS, then just wait for the next LTS where it will be included.

4 Likes

thanks for remembering me about the semantic versioning contract.

Having that in mind, it seems kind of fine to drop support for 1.0.x for me as a package maintainer as 1.x is still guaranteed to be compatible according to semantic versioning.

1 Like