[GH-ISSUE #951] 0.0.0 as unpublishable init version #1457

New Issue

GiteaMirror · 2026-04-16T10:52:10-05:00

GiteaMirror commented

2026-04-16 10:52:10 -05:00

Originally created by @hugollm on GitHub (Jun 11, 2023).
Original GitHub issue: https://github.com/semver/semver/issues/951

The idea is a simple rule to standardize how init tooling works. e.g.

New packages start at 0.0.0 but are unpublishable at this point.

Package registries should reject any attempt to publish a zero version. That would standardize the init version (which now usually ranges from 0.0.0 to 0.1.0) and also prevent any incomplete code to be published. Bonus points for eliminating ambiguity, aka. "is this 0.0.0 package valid or not?".

Originally created by @hugollm on GitHub (Jun 11, 2023). Original GitHub issue: https://github.com/semver/semver/issues/951 The idea is a simple rule to standardize how `init` tooling works. e.g. * New packages start at `0.0.0` but are unpublishable at this point. Package registries should reject any attempt to publish a zero version. That would standardize the init version (which now usually ranges from `0.0.0` to `0.1.0`) and also prevent any incomplete code to be published. Bonus points for eliminating ambiguity, aka. "is this 0.0.0 package valid or not?".

GiteaMirror closed this issue

2026-04-16 10:52:10 -05:00

GiteaMirror commented

2026-04-16 10:52:11 -05:00

@ljharb commented on GitHub (Jun 11, 2023):

Why? 0.0.0 is a perfectly valid version number, and npm init has started at 1.0.0 for many years.

@ljharb commented on GitHub (Jun 11, 2023): Why? 0.0.0 is a perfectly valid version number, and `npm init` has started at 1.0.0 for many years.

GiteaMirror commented

2026-04-16 10:52:12 -05:00

@bhetland commented on GitHub (Jun 11, 2023):

On 2023-06-11 Jordan Harband @.***> wrote:

Why? 0.0.0 is a perfectly valid version number

If anything, I would say semantics. I agree that as a version number per se it is still a perfectly valid one.

It would add a nice touch to the understanding of what such an identification would signify. A version 0.0.0 could for instance comprise nothing but metainformation about the API and/or software. Any version 0.0.z could indeed be considered non-functional and automated tooling may consider it unpublishable or rejectable. A vcs could conceivably also choose this as its default initial designation if it maintains such metainfo in the repository (e.g. before any file gets added to the repo).

Any version 0.y.z, where y > 0, would indicate a development version and considered not stable. Furthermore, as before no expectations about compatibility would apply to any version x.y.z when x < 1. (It has been my understanding that the semantic rulings of semver only apply when x > 0.)

The policy of how to handle anything 0.x.y would remain outside of the [semver] standard, but it would facilitate a differentiation between 0.r.p, 0.0.p and 0.0.0 if desired.

--
Ben Hetland @.***>

@bhetland commented on GitHub (Jun 11, 2023): On 2023-06-11 Jordan Harband ***@***.***> wrote: > Why? 0.0.0 is a perfectly valid version number If anything, I would say semantics. I agree that as a version number per se it is still a perfectly valid one. It would add a nice touch to the understanding of what such an identification would signify. A version 0.0.0 could for instance comprise nothing but metainformation about the API and/or software. Any version 0.0.z could indeed be considered non-functional and automated tooling may consider it unpublishable or rejectable. A vcs could conceivably also choose this as its default initial designation if it maintains such metainfo in the repository (e.g. before any file gets added to the repo). Any version 0.y.z, where y > 0, would indicate a development version and considered not stable. Furthermore, as before no expectations about compatibility would apply to any version x.y.z when x < 1. (It has been my understanding that the semantic rulings of semver only apply when x > 0.) The policy of how to handle anything 0.x.y would remain outside of the [semver] standard, but it would facilitate a differentiation between 0.r.p, 0.0.p and 0.0.0 if desired. -- Ben Hetland ***@***.***>

GiteaMirror commented

2026-04-16 10:52:12 -05:00

@ljharb commented on GitHub (Jun 12, 2023):

See #923 for a more realistic documentation of how v0 versions work in practice.

@ljharb commented on GitHub (Jun 12, 2023): See #923 for a more realistic documentation of how v0 versions work in practice.

GiteaMirror commented

2026-04-16 10:52:13 -05:00

@hugollm commented on GitHub (Jun 12, 2023):

Honestly, as a programmer I just get triggered by a count starting at 0.1.0, so I tought some semantics could be an incentive to start at zero. I think tooling starts at 0.1.0 today by total accident, because that's the example given in the documentation. Not because of the constraints themselves.

Everytime I bring this up with friends, the arguments against starting at zero are usually "but zero is nothing". So it seems there is some understanding that zero is not something ready or wathever.

I also figured a simple rule like that could be easier to make into the document than a bunch of semantics around zero versions.

My personal preference is:

0.0.0 // hello world
0.0.1 // alpha
0.1.0 // beta
1.0.0 // stable

But I guess that's too many rules around something that's supposed to be pre-release? I don't know, really.

@hugollm commented on GitHub (Jun 12, 2023): Honestly, as a programmer I just get triggered by a count starting at `0.1.0`, so I tought some semantics could be an incentive to start at zero. I think tooling starts at `0.1.0` today by total accident, because that's the example given in the documentation. Not because of the constraints themselves. Everytime I bring this up with friends, the arguments against starting at zero are usually "but zero is nothing". So it seems there is some understanding that zero is not something ready or wathever. I also figured a simple rule like that could be easier to make into the document than a bunch of semantics around zero versions. My personal preference is: ``` 0.0.0 // hello world 0.0.1 // alpha 0.1.0 // beta 1.0.0 // stable ``` But I guess that's too many rules around something that's supposed to be pre-release? I don't know, really.

GiteaMirror commented

2026-04-16 10:52:13 -05:00

@hugollm commented on GitHub (Jun 12, 2023):

Semver has no official value to indicate "no releases". 0.0.0 would be the perfect fit for that. Maybe that's better than "forbidden publish". As in: this package was not released yet, use at your own risk.

I believe golang puts 0.0.0 when you link something that has no version tags. That behavior seems very sane to me.

@hugollm commented on GitHub (Jun 12, 2023): Semver has no official value to indicate "no releases". `0.0.0` would be the perfect fit for that. Maybe that's better than "forbidden publish". As in: this package was not released yet, use at your own risk. I believe golang puts `0.0.0` when you link something that has no version tags. That behavior seems very sane to me.

GiteaMirror commented

2026-04-16 10:52:13 -05:00

@jwdonahue commented on GitHub (Jun 12, 2023):

Nobody cares what you use to version unpublished packages. By definition, SemVer only applies to published artifacts. Nothing in the spec requires that you start at 0.1.0, that's just a suggestion in the FAQ. It really doesn't matter whether you start at 0.0.0 or 0.1.0 or any other version for that matter.

Because SemVer is intended for published artifacts, and you may remove any version from a package feed or file share for any reason at any time, it really makes no difference at all what your visible version history appears to be. There are often gaps in the visible sequence and nobody really cares.

@jwdonahue commented on GitHub (Jun 12, 2023): Nobody cares what you use to version unpublished packages. By definition, SemVer only applies to published artifacts. Nothing in the spec requires that you start at 0.1.0, that's just a suggestion in the FAQ. It really doesn't matter whether you start at 0.0.0 or 0.1.0 or any other version for that matter. Because SemVer is intended for published artifacts, and you may remove any version from a package feed or file share for any reason at any time, it really makes no difference at all what your visible version history appears to be. There are often gaps in the visible sequence and nobody really cares.

GiteaMirror commented

2026-04-16 10:52:13 -05:00

@ljharb commented on GitHub (Jun 12, 2023):

Does go not have any kind of manifest, like npm's package.json? If not, that might be the real problem here - in npm, git tags only exist for published releases, including 0.0.0, so there simply wouldn't be a version number unless there's a release.

@ljharb commented on GitHub (Jun 12, 2023): Does go not have any kind of manifest, like npm's package.json? If not, that might be the real problem here - in npm, git tags only exist for published releases, including 0.0.0, so there simply wouldn't *be* a version number unless there's a release.

GiteaMirror commented

2026-04-16 10:52:14 -05:00

@hugollm commented on GitHub (Jun 13, 2023):

Go has go.mod but it relies on versions being tagged in git, as far as I know.

About "the real problem", I don't think there's even a big problem to be solved. I created this issue more as a suggestion and to hear feedback. I do care about consistency in my tooling.

I've seem some repos on github with a "discussions" section, I guess that would probably be a more appropriate place for this. But the site did send me here for feedback. haha ~ I'll just go ahead and close this since there's nothing actionable.

@hugollm commented on GitHub (Jun 13, 2023): Go has `go.mod` but it relies on versions being tagged in git, as far as I know. About "the real problem", I don't think there's even a big problem to be solved. I created this issue more as a suggestion and to hear feedback. I do care about consistency in my tooling. I've seem some repos on github with a "discussions" section, I guess that would probably be a more appropriate place for this. But the site did send me here for feedback. haha ~ I'll just go ahead and close this since there's nothing actionable.

GiteaMirror commented

2026-04-16 10:52:15 -05:00

@Nikasyo25 commented on GitHub (Jun 14, 2023):

What should I do guide me will you please

Sent from Outlook for Androidhttps://aka.ms/AAb9ysg

From: Jordan Harband @.>
Sent: Monday, June 12, 2023 6:22:07 PM
To: semver/semver @.>
Cc: Subscribed @.***>
Subject: Re: [semver/semver] 0.0.0 as unpublishable init version (Issue #951)

Does go not have any kind of manifest, like npm's package.json? If not, that might be the real problem here - in npm, git tags only exist for published releases, including 0.0.0, so there simply wouldn't be a version number unless there's a release.

—
Reply to this email directly, view it on GitHubhttps://github.com/semver/semver/issues/951#issuecomment-1587750337, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A3FXP3M6NB7DJRWTJAQZSU3XK5F37ANCNFSM6AAAAAAZCO3OIE.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

@Nikasyo25 commented on GitHub (Jun 14, 2023): What should I do guide me will you please Sent from Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Jordan Harband ***@***.***> Sent: Monday, June 12, 2023 6:22:07 PM To: semver/semver ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [semver/semver] 0.0.0 as unpublishable init version (Issue #951) Does go not have any kind of manifest, like npm's package.json? If not, that might be the real problem here - in npm, git tags only exist for published releases, including 0.0.0, so there simply wouldn't be a version number unless there's a release. — Reply to this email directly, view it on GitHub<https://github.com/semver/semver/issues/951#issuecomment-1587750337>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A3FXP3M6NB7DJRWTJAQZSU3XK5F37ANCNFSM6AAAAAAZCO3OIE>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#1457