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 …

[image] chakravala: basically, I only tag releases as a courtesy so that other people with less time on their hands can keep up with my work in computer algebra… Well, why didn’t you just admit this from the start? That you are only trying to make things easy for yourself instead of pretendin…

I want to point out that the current state of affairs have to be the default because it is the one that keeps code working. However, it does not mean that we can’t have: Flags to Pkg to “turn off the resolver” or give other hints to it. pkg> add A B C --force-latest or something Better tooling to …

Just as a side note, an interesting thing to consider is that the feedback from doing something like this (keep code working but with some drawbacks in some cases) will, almost by construction, only be negative. The reason is that you will never hear from someone saying “I added packages A, B and C …

I have been thinking about this after reading all the comments here and there are a lot of comments. And I have found the perfect solution for everyone which is guaranty to work. There are of course a few rules to follow: But first, the solution. The solution is that this is a FALSE PROBLEM. It i…

It does create other problems though. Consider your package is using two packages A and B which depend of OffsetArrays0001.jl and OffsetArrays0002.jl. Now your package gets an OffsetArray from A and one from B and wants to add them: that does not work because those two are different types: OffsetAr…

[image] StevenSiew: Here is the solution Name your packages PackageName0001 (eg. OffsetArrays0001.jl ) Maintain Forward Compatibility at all cost If you cannot maintain Forward Compatibility then create a new package called PackageName0002 (eg. OffsetArrays0002.jl ) [Spec-ulation Ke…

mauro3, you are right. I didn’t think about that.

I would like to highlight the constructive advice of the original post, which solves the greatest part of the conflict between adding or not adding upper compat bounds: [image] ExpandingMan: When developing your code, I strongly recommend commenting out the compat section entirely so that you a…

[image] heliosdrm: And I daresay could be automated too. Safe compat bounds can be found out from the package’s Manifest.toml in a status where the tests pass Maybe you missed it, but I think that [image] GitHub - JuliaRegistries/CompatHelper.jl: Automatically update the [compat]... …

Please be mindful of version bounds and semantic versioning when tagging your packages

Community

kristoffer.carlsson November 5, 2019, 9:57am 51

argues similarly in that a breaking version is effectively the same as to just rename the package.

The whole video is a good watch for people interesting in these things.

Topic		Replies	Views
Announcement: automatic merging for the General registry Community package , announcement , pkg , announcements , package-manager	64	5118	December 23, 2019
Dependency problem with FIllArrays General Usage pkg	41	2540	April 26, 2019
Bounds on package versions Internals & Design question , package	10	1087	March 5, 2020
New automerge requirement: Release notes required for breaking package releases Package Announcements general-registry , registryci	50	1832	January 2, 2025
Would slowing Julia's release cadence improve ecosystem quality? Community	98	5766	September 15, 2023

Please be mindful of version bounds and semantic versioning when tagging your packages

Related topics