# Encouraging 1.x versions for registered packages?

**URL:** <https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171>\
**Category:** Package Management\
**Created:** [April 1, 2023, 1:59am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171 "2023-04-01T01:59:05Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Alec\_Loudenback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/alec_loudenback/32/278_2.png) [@Alec\_Loudenback](https://discourse.julialang.org/u/Alec_Loudenback)\
**Post date:** [April 1, 2023, 1:59am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/1 "2023-04-01T01:59:05Z")

</div>

I’ve become a fan of pretty early on in a package’s development going to v1.X.X so that you have more flexibility in SemVer. This gives you a little bit more flexibility for how it impacts dependencies from the get-go.

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [April 1, 2023, 2:38am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/2 "2023-04-01T02:38:32Z")

</div>

Yep.  
I start all packages at `v1.0.0`  
It’s now the default in PkgTemplates.jl

---

<div class="post-metadata">

**Author:** ![jlapeyre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlapeyre/32/4514_2.png) [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)\
**Post date:** [April 1, 2023, 6:15am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/3 "2023-04-01T06:15:15Z")

</div>

Could you or @oxinabox elaborate a bit?

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [April 1, 2023, 6:32am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/4 "2023-04-01T06:32:39Z")

</div>

Interesting. We should relegate v0 to indicate pre-registration status. Perhaps package registration should only automerge packages at v1 into the registry?

---

<div class="post-metadata">

**Author:** ![abulak](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/abulak/32/28314_2.png) [@abulak](https://discourse.julialang.org/u/abulak)\
**Post date:** [April 1, 2023, 8:34pm UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/5 "2023-04-01T20:34:22Z")

</div>

I don’t quite understand what’s the point of versioning packages which are not in (some) registry;

To me version `0.x.y` simply means

- the package is not yet in the finished (=complete) state, BUT
- the authors are willing to use it anyway, and
- they are happy if people go out and battle-test it as well.

If one is not using actively a package and sees no real use for external users (or is not happy with them using it) then why even register (and bump versions, etc)?

@oxinabox why is starting at `1.0.0` any better than `0.1.0`? (especially with julia provision on semver?)

---

<div class="post-metadata">

**Author:** ![e3c6](https://avatars.discourse-cdn.com/v4/letter/e/e79b87/32.png) [@e3c6](https://discourse.julialang.org/u/e3c6)\
**Post date:** [April 2, 2023, 11:32am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/6 "2023-04-02T11:32:49Z")

</div>

> [@mkitti](#):
>
> Perhaps package registration should only automerge packages at v1 into the registry?

+1 to this.

Just remove all the special Julia semver provisions for 0.x.y (except maybe for already registered packages). Would be simpler, IMHO.

---

<div class="post-metadata">

**Author:** ![gustaphe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gustaphe/32/18174_2.png) [@gustaphe](https://discourse.julialang.org/u/gustaphe)\
**Post date:** [April 2, 2023, 12:07pm UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/7 "2023-04-02T12:07:01Z")

</div>

Because a `0.y.z` package has only two levels available: breaking and non-breaking. `x.y.z` packages can differentiate two non-breaking levels, where `z` is patches and `y` is features. Before `1.0.0` you cannot tell what kind a release is.

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [April 3, 2023, 2:28am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/8 "2023-04-03T02:28:40Z")

</div>

> I don’t quite understand what’s the point of versioning packages which are not in (some) registry;

There is none, normally. Potentially one might have internal use cases for it, like some set of milestones before release.

That’s one of the arguments for why we should start at 1.0.0.  
Semver 2 (without the Julia extension) says that you should go to v1.0.0 as soon as you begin distributing the software, which in Julia-land means registering the package.

The others include what @gustaphe said:

> Because a `0.y.z` package has only two levels available: breaking and non-breaking. `x.y.z` packages can differentiate two non-breaking levels, where `z` is patches and `y` is features. Before `1.0.0` you cannot tell what kind a release is.

and also that people forget the julia extension and mistakenly take a release that is nonbreaking as 0.x.0 because it adds new features.

And finally, the one that motivates this whole discussion thread:  
if you start at 1.0.0 you don’t need to make a breaking release when you realise the package is done at v0.7.4

---

<div class="post-metadata">

**Author:** ![bilderbuchi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bilderbuchi/32/13562_2.png) [@bilderbuchi](https://discourse.julialang.org/u/bilderbuchi)\
**Post date:** [April 3, 2023, 5:11am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/9 "2023-04-03T05:11:11Z")

</div>

Do I understand the argument made here correctly that:

- people should start registering packages at 1.0
- let’s say one publishes a package to obtain usage and user feedback to identify API problems before becoming stable.
- In vanilla semver, those would be a succession of 0.\* releases.
- In julia-flavour semver, and following the above recommendation, after, say, 4 api-correcting (breaking) releases, you end up with e.g. 5.4 where you consider the API “done”. Correct?

As a comparative julia “newbie”, i find this confusing, and I think it loses the "signalling effect of package version 1.0 a bit:

> Version 1.0.0 defines the public API.

---

<div class="post-metadata">

**Author:** ![bilderbuchi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bilderbuchi/32/13562_2.png) [@bilderbuchi](https://discourse.julialang.org/u/bilderbuchi)\
**Post date:** [April 3, 2023, 5:21am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/10 "2023-04-03T05:21:30Z")

</div>

> [@oxinabox](#):
>
> Semver 2 (without the Julia extension) says that you should go to v1.0.0 as soon as you begin distributing the software

Can you point out which part of semver says that? I found that bit surprising, and just re-read the definition, and could not find a passage that I would interpret this way? 🤔

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [April 3, 2023, 5:29am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/11 "2023-04-03T05:29:20Z")

</div>

It’s been a bit since i read it, and i mangled it slightly by here is the relevant bit

> ### 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 backwards compatibility, you should probably already be 1.0.0.

For open-source libraries users **immediately** depend on your API.  
I guess you could argue if your users are not really depending on your package for anything important … but that’s out of your hands in open-source.

I have argued a few times that we should have a Unstable registry which allows people to register stuff pre-1.0.0, and allows them to depend on other unstable things, or things from General. TBH I don’t care that much.

---

<div class="post-metadata">

**Author:** ![gustaphe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gustaphe/32/18174_2.png) [@gustaphe](https://discourse.julialang.org/u/gustaphe)\
**Post date:** [April 3, 2023, 5:31am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/12 "2023-04-03T05:31:23Z")

</div>

To me, when you’re looking for feedback on the API you should be distributing the repo url, registering _is_ making an API commitment. Not a permanent one, but that’s what major versions are for.

---

<div class="post-metadata">

**Author:** ![jishnub](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jishnub/32/33620_2.png) [@jishnub](https://discourse.julialang.org/u/jishnub)\
**Post date:** [April 3, 2023, 6:02am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/13 "2023-04-03T06:02:08Z")

</div>

That’s a catch-22 situation, since the feedback one seeks often only arrives after other packages have tried to use it as a dependency, and that will only happen once the package is registered.

---

<div class="post-metadata">

**Author:** ![tecosaur](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tecosaur/32/23206_2.png) [@tecosaur](https://discourse.julialang.org/u/tecosaur)\
**Post date:** [April 3, 2023, 6:11am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/14 "2023-04-03T06:11:52Z")

</div>

This is an interesting tangent to me, because I have a trio of packages that depend on each other and are in active “breaking change every few commits” development. For them I’m feeling that `v0.x` development is working quite well. They are _going_ to reach a point where I’m happy with the design/API within the next few months. Without registering them getting the docs build/tests to work would have been quite a bit more hassle.

I think linking _announcing_ a package for use and tagging `1.0` should go together, but it’s useful to have `0.x` packages registered.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [April 3, 2023, 7:46am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/15 "2023-04-03T07:46:59Z")

</div>

> [@oxinabox](#):
>
> if you start at 1.0.0 you don’t need to make a breaking release when you realise the package is done at v0.7.4

What’s the difference between realizing “the package is done” at v0.7.4 (if started with v0.1) versus at v7.4 (if started with v1)?  
I don’t see anything practical aside from having two non-major version numbers.

---

<div class="post-metadata">

**Author:** ![e3c6](https://avatars.discourse-cdn.com/v4/letter/e/e79b87/32.png) [@e3c6](https://discourse.julialang.org/u/e3c6)\
**Post date:** [April 3, 2023, 9:12am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/16 "2023-04-03T09:12:12Z")

</div>

> [@bilderbuchi](#):
>
> signalling effect of package version 1.0

I think this is overrated. We should only distinguish breaking vs. non-breaking changes. The “signalling effect” of a package’s stability will come automatically, as the amount of time it stays still without new breaking releases.

---

<div class="post-metadata">

**Author:** ![e3c6](https://avatars.discourse-cdn.com/v4/letter/e/e79b87/32.png) [@e3c6](https://discourse.julialang.org/u/e3c6)\
**Post date:** [April 3, 2023, 9:12am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/17 "2023-04-03T09:12:38Z")

</div>

> [@aplavin](#):
>
> I don’t see anything practical aside from having two non-major version numbers.

Just this.

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [April 3, 2023, 9:25am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/18 "2023-04-03T09:25:47Z")

</div>

> I don’t see anything practical aside from having two non-major version numbers.

The other reason I forgot, is the reason why having two nonbreaking version numbers is actually really important.  
It allowed backporting fixes.

Since new features, including **change of compatibility** with other packages, lead to a `1.x.0` release  
there is space to back-port bug fixes into any of the patch release numbers.  
This means if you have users locked out of using the latest release because of incompatibility with dependencies, you can still back-port fixes for them.  
We used to do this a lot at Invenia.  
One team would be moving the latest version of the API ahead, breaking compatibility etc as needed to use latest tools.  
while another team worked on a system that used that library on the old API to accomplish some goal.  
And then bug-fixes could be sent back to the users versions ago.

You see this a fair bit for Julia itself.  
Backporting bugfixes to the LTS.

---

<div class="post-metadata">

**Author:** ![cstjean](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cstjean/32/1444_2.png) [@cstjean](https://discourse.julialang.org/u/cstjean)\
**Post date:** [April 3, 2023, 10:51am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/19 "2023-04-03T10:51:31Z")

</div>

I get the arguments, but at the same time, I like how Julia did it. One breaking release per year from 0.1 to 0.7, then using 1.0 as a “this is stable / ready” marker. Otherwise, how would you do it? Julia 1.0 to 7.0 as “beta”, then you make a big party for Julia 8.0? Wouldn’t feel the same.

---

<div class="post-metadata">

**Author:** ![e3c6](https://avatars.discourse-cdn.com/v4/letter/e/e79b87/32.png) [@e3c6](https://discourse.julialang.org/u/e3c6)\
**Post date:** [April 3, 2023, 11:04am UTC](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171/20 "2023-04-03T11:04:33Z")

</div>

I would say it’s not fair to compare Julia the language itself, to how we should treat packages.

Consider that before v0.6 (I think) there was no Pkg (as we know it today, with Project.toml and so on) and how versions were resolved was different , etc.

[Next page](https://discourse.julialang.org/t/encouraging-1-x-versions-for-registered-packages/97171.md?page=2)