If a package becomes stable at a 0.x.y release (i.e. no future breaking changes are expected) how should that be tagged? Tagging 1.0.0 is nice because it gives some people the impression that there are no more intended breaking changes and because it allows patch releases, but it also requires all …

Maybe this is a question for CompatHelper? If CompatHelper can figure out automatically that between 0.x.y and 1.0.0 there were no commits and that the new release just signals the intention of stability it could automatically mention that in the PR?

I think the most reliable way for CompatHelper to detect that there were no breaking changes would be an “@CompatHelper 1.0.0 does not introduce any breaking changes” comment in the repository which released 1.0.0 which could be reproduced on CompatHelper PRs as a follow-up comment “1.0.0 does not i…

There is a mechanism for communicating release notes at registration time: https://github.com/JuliaRegistries/Registrator.jl#release-notes . Those show up in the PRs to General. Maybe CompatHelper could be taught to find those and put them in the compat-bumping PRs. So then the release notes could sa…

Well, I’d guess that if the package is stable then imposing a one-time change for dependents to update their compat bounds isn’t such a burden. This is one of the joys of maintaining a package. CompatHelper makes it pretty easy. I do not think that having CompatHelper do this automatically would wor…

Here are some examples of popular packages that seem to be in this state julia> filter(x -> x.version.major < 1 && x.version.patch ≥ 10, df)[1:10,:] 10×4 DataFrame Row │ name version dependents downloads │ String VersionN… Int64 Int64 ─────┼─────────…

StatsBase and Distributions both have some tech debt (they are old packages and you can clearly see that parts of the code are from the Julia 0.2 days!) and planned breaking improvements, but we’re very slow to do a new breaking release because they have a huge number of direct and indirect dependen…

As said, and for interest Invenia has made it a policy of not doing 0.x.y releases any more. All new project are created at 1.0.0 and we are closing out all out internal packages to just jump straight to 1.0.0 ASAP (i thought we had gotten all of them ages ago but found some more that were not cur…

When a downstream package marks a compat entry of 0.3 they indicate that they are happy with version 0.3.0 and any future versions that their dependant declares are non-breaking. It seems fair, then, to add a flag in the registry that indicates 1.0 is nonbreaking which would not require making chang…

[image] Lilith: When a downstream package marks a compat entry of 0.3 they indicate that they are happy with version 0.8.0 and any future versions that their dependant declares are non-breaking. Nit: according to Pkg, 0.8 is breaking compared to 0.3. Versions before 1.0 means that minor versi…

What to do about defacto stability before 1.0

Community

StefanKarpinski August 10, 2022, 2:55pm 7

This is what I’d recommend and what I’ve done myself with the handful of packages I maintain: bite the bullet and go to 1.0 when it seems ready and adjust anything that has compat bounds that include the last version to also include 1.0.

Topic		Replies	Views
Getting to 1.0 -- How can we get packages to "make that tag"? Community	17	1584	April 20, 2021
Encouraging 1.x versions for registered packages? Package Management	74	3149	April 23, 2023
Package compatibility caps Announcements announcement , packages , package-manager	55	6426	October 12, 2018
New automerge requirement: Release notes required for breaking package releases Package Announcements general-registry , registryci	50	2239	January 2, 2025
Please be mindful of version bounds and semantic versioning when tagging your packages Community	143	10504	November 18, 2019

What to do about defacto stability before 1.0

Related topics