# How can we encourage Julia package developers to release version 1.0.0?

**URL:** <https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124>\
**Category:** Community\
**Tags:** package, release, pkg, development, releases\
**Created:** [September 24, 2019, 6:06pm UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124 "2019-09-24T18:06:43Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![tkf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkf/32/17635_2.png) [@tkf](https://discourse.julialang.org/u/tkf)\
**Post date:** [September 24, 2019, 10:49pm UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/5 "2019-09-24T22:49:52Z")

</div>

Quoting my comments from the earlier discussion:

> IMHO, encouraging major bump too much is risky. I think it would be nice to even mention that updating timescale of major versions should be targeting at least about a year and discouraging 1.0 if they can’t foresee stability more than a few months. The emphasis on timescale is somewhat inspired by [Numpy’s proposed deprecation policy](https://numpy.org/neps/nep-0023-backwards-compatibility.html) which discusses update frequency of users and deprecation periods. They are not using SemVer but I think the basic idea applies. Of course, I know that not all Julia packages have to be as stable as Numpy.
> 
> — [Answer to be documented: Is it OK to register a package as 0.x.(y+1) when it is backward-compatible to 0.x.y but has feature additions? · Issue #1417 · JuliaLang/Pkg.jl · GitHub](https://github.com/JuliaLang/Pkg.jl/issues/1417#issuecomment-534432884)

> Although I do admire all the effort of Julia core team to support backward compatibility based on PkgEval for all the registered packages, I find it unsatisfactory to call a software stable without clearly written deprecation policy. Unfortunately, it seems that the discussion [JuliaLang/Juleps#51](https://github.com/JuliaLang/Juleps/issues/51) is stalled.
> 
> Without `julia` itself having clear deprecation policy, there is no clear reference point for Julia package authors to understand what it means to be 1.0.
> 
> Another reason to avoid recommending 1.0 prematurely is that there is no clear definition of public API (I discussed it briefly in [Julia's Release Process - #8 by tkf](https://discourse.julialang.org/t/julias-release-process/28122/8) and [Julia's Release Process - #14 by tkf](https://discourse.julialang.org/t/julias-release-process/28122/14))
> 
> — [Answer to be documented: Is it OK to register a package as 0.x.(y+1) when it is backward-compatible to 0.x.y but has feature additions? · Issue #1417 · JuliaLang/Pkg.jl · GitHub](https://github.com/JuliaLang/Pkg.jl/issues/1417#issuecomment-534774283)

---

_[View the full topic](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124)._