Auto block registration of packages pre-1.0

[oxinabox]

From SemVer 2.0

How do I know when to release 1.0.0?

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.

I am going to argue that this is normally actually the case when you register in general.
If you don't intend for people to use it you shouldn't be registering it.
Perhaps by exception people are registering with intent to iterate rapidly in a breaking way.
But it is exceptional and we can always use the functionality to bypass that rule.

It's problematic we people register pre-1.0
Because

1. People struggle to draw the line when to hug 1.0, but on registration is a good time
2. Releasing 1.0 once "stability is achieved" is breaking for no reason.
3. They can't use full range of semver 3 digits, which makes backporting sometimes impossible.

I propose we only enforce this on new package registration. And allow old packages to be grandfathered.

We have talked about this on and off for years

[tecosaur]

I don't think it would be a good hard rule to have, but I think it would be a good guideline/soft check.

I have one or two packages that are 0.x myself at the moment, because they're just about useful enough to be registered but still very much having their API/design worked out.

In most cases though, I think it's very useful to have the three channels of information in the version number:

• Breaking changes
• New features
• Bugfixes

So perhaps a way this could be done is as an automerge check, allowing for manual intervention if the registrant insists that they've thought about it and really do want 0.x?

[oxinabox]

So perhaps a way this could be done is as an automerge check, allowing for manual intervention if the registrant insists that they've thought about it and really do want 0.x?

I agree.
We make it an automerge check, and be generous with exceptions.
And since I propose only doing that check it at registration time, it will not be too much barrier or inconvenience.
Since once registered would be allowed to continue.

[Tortar]

I'm not sure if following SemVer prescription would be beneficial in this case. I think this would encourage people to release a 1.0 version when the API is not ready. Considering the amount of packages which are still in <1.0 stage in the Julia ecosystem, it seems that many mantainers feel like their packages are still not ready for a 1.0 release, which is more a lack of time maybe than anything else. This seems to me an artificial solution to a different underling problem.

[oxinabox]

I would argue its actually the opposite.
There are so so many packages with very stable API that haven't changed in years that are pre-1.0
there is no cost for initially releasing at 1.0 and then releasing 2.0 later.

[tecosaur]

To me the motivating issue here is that we have a bunch of 0.x packages that release versions with new features, don't break API, but are considered a semver breaking release because they don't have access to that crucial third channel of semver information.

This results in needless comparability bound churn across the ecosystem. This is the problem that I see this proposal helping with.

I don't quite understand this view that occasionally seems to pop up that 1.0 is for the "finished"/"fully worked out" version of the software: it's really just for as soon as you start caring about having a public API. Agents.jl is on v6 last I checked, and that's great!

[Tortar]

if that is the ratio of the proposal @tecosaur I'm more convinced now that it's probably a good idea actually, I didn't consider the problem of having breaking releases for new features. And also the reasoning of @oxinabox seems right, but maybe it's more debatable why mantainers didn't release a 1.0 for years. But that is not the point maybe. So for what is worth I would reconsider my position :-) But it doesn't seem a good hard rule also to me anyway.