# 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:** 20
**Page:** 1
### Author:  [@dilumaluthge](https://discourse.julialang.org/u/dilumaluthge)
#### Post date: [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/1 "2019-09-24T18:06:43Z")
For the overwhelming majority of Julia packages registered in the [General registry](https://github.com/JuliaRegistries/General), the latest release of the package has version of the form `0.X.Y`. (See the table at the bottom of this post.)
As the Julia ecosystem continues to mature and stabilize, it would be great if the authors of stable Julia packages could start releasing `1.0.0` versions of their packages.
What strategies can we use to encourage and incentivize the developers of Julia packages to release version `1.0.0` of their package?
| Major version number of the most recent release | Number of packages |
| --- | --- |
| 0 | 2678 |
| 1 | 317 |
| 2 | 64 |
| 3 | 25 |
| 4 | 15 |
| 5 | 8 |
| 6 | 7 |
| 7 | 2 |
| 8 | 1 |
| 9 | 0 |
| 10 | 1 |
| 11 | 0 |
| 12 | 0 |
| 13 | 0 |
| 14 | 0 |
| 15 | 0 |
| 16 | 1 |
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [September 24, 2019, 7:00pm UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/2 "2019-09-24T19:00:36Z")
> [@dilumaluthge](#):
>
> What strategies can we use to encourage and incentivize the developers of Julia packages to release version `1.0.0` of their package?
A blog post on [the Julia blog](https://julialang.org/blog/) that just encourages this practice and points out the advantages may be a good start.
The main advantage is being able to follow [SemVer](https://semver.org/) (from the package side) and rely on it (for the dependent packages).
And of course releasing an 1.0 does not impose any relevant constraints on the maintainers, just that they bump major/minor versions whenever they make a breaking/extending change, respectively.
---
### Author:  [@tlienart](https://discourse.julialang.org/u/tlienart)
#### Post date: [September 24, 2019, 10:21pm UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/3 "2019-09-24T22:21:06Z")
It’s hard right? A lot of these would be maintained by casual passionate users who’ve already spent a lot of time trying to bring things to just work well; releasing a 1.0 is (at least it seems to me) a strong signal indicating that you as a dev believe that the package API is ready and that you will commit to maintaining it long term. This may seem like a big step to casual devs, even if I agree with @Tamas_Papp that 1.0 shouldn’t be really special but then why try pushing devs to release 1.0?
So I guess my question is: why do we care whether it’s 1.0? Is the underlying request that package devs accelerate a relative freeze of their API? Apart from packages that offer very narrow functionalities, I think that’s a big step to ask of devs.
Here’s another point: sklearn is used by millions and is 0.23; does that bother anyone?
---
### Author:  [@oxinabox](https://discourse.julialang.org/u/oxinabox)
#### Post date: [September 24, 2019, 10:29pm UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/4 "2019-09-24T22:29:32Z")
My thought process is that if you expect to make more than 1 breaking change in the next 12 months.
i.e. you have multiple planned breaking change sets, then it is not time to tag 1.0 yet.
That is not to say that you can’t later release 2.0 and 3.0 in the same year, but to an extent you don’t want to expect to.
But that is why many of my packages, even ones used in production systems, are not tagged 1.0
Otherrs are not tagged 1.0 because they entered defacto stability, without concious effort on my part.
They just stopped having things I needed to change in them.
> Here’s another point: sklearn is used by millions and is 0.23; does that bother anyone?
IIRC, Sklearn doesn’t follow SemVer. SemVer is relatively young.
---
### Author:  [@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")
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)
---
### Author:  [@tkf](https://discourse.julialang.org/u/tkf)
#### Post date: [September 24, 2019, 10:56pm UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/6 "2019-09-24T22:56:19Z")
> [@oxinabox](#):
>
> IIRC, Sklearn doesn’t follow SemVer.
Python ecosystem does not use SemVer (in general). But I find Pythonistas very careful about compatibility (probably because the package manager had been awful, as [Armin Ronacher](http://lucumr.pocoo.org/) hypothesised).
---
### Author:  [@anon92994695](https://discourse.julialang.org/u/anon92994695)
#### Post date: [September 24, 2019, 11:58pm UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/7 "2019-09-24T23:58:01Z")
As a package maintainer who hasn’t hit 1.0 I’d like to share whats holding me back.
Here’s my crude release plan for my package at version 0.51:
```julia
* < 0.3.0 : Mapping functionality, prototyping*
* < 0.5.0 : Testing via actual usage on real data, look for missing essentials*
* < 0.6.0 : Bake in convenience functions for ease of use. Flesh out Documentation.*
< 0.7.5 : Public input (find those bugs!). Adequate Unit Tests.
< 1.0.0 : Focus on performance, stability, generalizability, lock down the package syntax.
```
Thus far I have a few users, some have been vocal(thank you!), other’s have came and left. Adding unit tests, convenience functions, and finding bugs requires a community. Releasing a high end package by yourself is time consuming. The fine soft-ware engineering details(docs, CICD, syntax, performance, etc) can be really cumbersome when there isn’t a pay-check attached. Community is everything when it comes to this sort of thing - so far no one else has actually added code to my package other then myself - that’s life.
In my opinion - a lot of packages have been abandoned/grown stagnant because the involvement from others outside of a few core areas is really minimal. So to me the question should maybe read “How do we encourage programmers/end-users to adopt Julia?”.
I could say, “my package could easily lead to an academic publication, come contribute”! But, then people would hop on board for the wrong reasons and potentially contribute suboptimally. Incentive, comes from the community, and productivity when money is off the table. The Julia community needs to be warm to new-comers, otherwise it will succumb to the second law prior to reaching maximal utility.
---
### Author:  [@chakravala](https://discourse.julialang.org/u/chakravala)
#### Post date: [September 25, 2019, 12:22am UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/8 "2019-09-25T00:22:17Z")
> [@dilumaluthge](#):
>
> What strategies can we use to encourage and incentivize the developers of Julia packages to release version `1.0.0` of their package?
Semantic versioning is used, so a 1.0 tag carries semantic significance. Packages may have a lot of breaking changes planned before their 1.0 release, which means that to reach 1.0 they would have to put in time and effort into reaching that goal.
Therefore, we should not arbitrarily tell package developers to start tagging a 1.0 release, since the release progression depends on what the plans and goals of the developers and sponsors are.
If you want to incentivize developers to reach a certain goal in a planned release and provide long term support, the best way would probably be to pay the developers for the time needed to reach those goals. As a self-funded developer, I wouldn’t appreciate it if a non-collaborator is pressuring me to meet some goal. However, if they financially compensated me for my time to meet their demands, that would be incentive.
---
### Author:  [@anon92994695](https://discourse.julialang.org/u/anon92994695)
#### Post date: [September 25, 2019, 12:38am UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/9 "2019-09-25T00:38:57Z")
Although getting paid would be great and all - really just a helping hand to help implement best practices for some things would be huge for me. It took me like 3 days to get CICD working and a week worth of afternoons (after work) to get my docs spun up.
Maybe that’s a point? Would making the dev ops, maintenance, or debugging easier draw in more people? Could we make it so more specialists (IE: a geophysicist not a software developer) can more easily learn the ropes to package development/management? What steps could be removed to make this less like “work” and more like “fun”?
Maybe we could make a survey to find peoples pain points? Then the Julia Pro’s could hit those? Could we use the deprecation of packages without [compat 1.0] in it as a chance to gather data (what happened)?
In my opinion once you get more specialists making packages, more people in those areas of study will trickle in. I know people who are worth their weight in gold in their specialty (involving scientific computing) but if you asked them to use github, or CICD, etc, they might as well be the newest novice ever to have noveled.
Maybe we could have a monthly lottery where the Julia Pro’s dedicate some time(couple hours or something) to helping out a “promising” package or developer. Think of it as a ripple effect. More people who know how to make high quality packages, will echo. More examples and maybe more contributions from that developer(gamble). But also, more exposure!
---
### Author:  [@tkf](https://discourse.julialang.org/u/tkf)
#### Post date: [September 25, 2019, 1:06am UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/10 "2019-09-25T01:06:12Z")
For anybody interested in this topic, I highly recommend watching Rich Hickey’s talk explaining why SemVer is bad (if you bump major version you might as well change the name) and how Go implemented a similar idea in a SemVer-compatible way.
[ ](https://www.youtube.com/watch?v=oyLBGkS5ICk)
[ ](https://www.youtube.com/watch?v=F8nrpe0XWRg)
I know the previous discussion on how Go’s major bump strategy may not fit well with nominal typing in Julia ([Pkg3 vs. Go's vgo](https://discourse.julialang.org/t/pkg3-vs-gos-vgo/10154)) but there is a recent proposal in Julia’s issue tracker that makes a similar strategy possible (optionally) [Taking package names less seriously · Issue #33047 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/33047)
I am not arguing that Go’s strategy should be recommended unconditionally. I just think it’s a good view point to understand before advocating 1.0 in Julia ecosystem.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [September 25, 2019, 6:22am UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/11 "2019-09-25T06:22:51Z")
> [@tlienart](#):
>
> releasing a 1.0 is (at least it seems to me) a strong signal indicating that you as a dev believe that the package API is ready and that you will commit to maintaining it long term
I understand why people may think that, but if we try to load too much information into package version numbers (both SemVer and commitment to maintenance) we end up with a suboptimal situation where neither goal is served.
Version numbers simply help dependent packages do upgrades in a scheduled and predictable manner: if the package follows SemVer, by fixing compat to `^1`, you can rest assured that nothing should break even if a new version is released, regardless of whether it is a `1.x` or a `2.0` release (because the latter won’t be used). Then, when you learn about a `2.0` release with breaking changes, you can review the `CHANGELOG` (ideally) and make the required changes in the dependent package when time permits, instead of having things in an inconsistent state.
It is easy to answer when one should release `1.0`: _when you have packages depending on your package_. You can learn this either from the registry, or informally for unregistered packages. Then, if you want to be nice to those other maintainers, it is time to leave `0.x.x` land (where basically anything goes in SemVer) and just release a `1.0`.
I think this should be the social norm in the community. Conversely, if a maintainer is unwilling to release a `1.0` despite requests, that should be a strong signal that the package is not reliably maintained. It is important to know this, but it is simply not true for a lot of `0.x` packages in the ecosystem, many are consistently maintained and have a lot of dependents.
Incidentally, commitment to maintenance is very difficult to signal reliably. Someone may be committed to maintenance, but just be busy at a given time. Or be interested in maintaining a package for years, then lose interest and abandon it. This is fine, and if the package is useful there should be a culture of adding collaborators, transferring the repository to someone who is interested, or if neither of those happens, forking.
---
### Author:  [@chakravala](https://discourse.julialang.org/u/chakravala)
#### Post date: [September 25, 2019, 8:21am UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/12 "2019-09-25T08:21:01Z")
> [@Tamas\_Papp](#):
>
> It is easy to answer when one should release `1.0` : _when you have packages depending on your package_.
Disagree on this one here. I don’t see any issue with depending on a package pre-1.0, it semantically means that if you chose to depend on it, you may have to deal with breaking changes on a minor version bump. If major breaking changes are no longer expected, then the package would be ready for 1.0 release. By following the SemVer, it helps signal API stability.
> [@Tamas\_Papp](#):
>
> Conversely, if a maintainer is unwilling to release a `1.0` despite requests, that should be a strong signal that the package is not reliably maintained.
This sounds a bit like an over generalization. It could be that the package is not ready for 1.0 but is being actively maintained and developed with changes. Rejecting a request for making a 1.0 tag would not automatically generalize to it being unmaintained.
However, if the package author doesn’t respond at all, then that would indeed be a signal that the package is not being maintained (since there is no response).
> [@anon92994695](#):
>
> I know people who are worth their weight in gold in their specialty (involving scientific computing) but if you asked them to use github, or CICD, etc, they might as well be the newest novice ever to have noveled.
> [@anon92994695](#):
>
> really just a helping hand to help implement best practices for some things would be huge for me. It took me like 3 days to get CICD working and a week worth of afternoons (after work) to get my docs spun up.
> [@anon92994695](#):
>
> Maybe we could have a monthly lottery where the Julia Pro’s dedicate some time(couple hours or something) to helping out a “promising” package or developer. Think of it as a ripple effect. More people who know how to make high quality packages, will echo. More examples and maybe more contributions from that developer(gamble). But also, more exposure!
Isn’t that what this discourse is for? If you have trouble with setting up your package development, all you have to do is open a topic here (equivalent of buying the lottery ticket) and if you are lucky somebody will spend the time to help you out with that problem. Usually the people on this discourse are quite helpful. If those specialists are unwilling to ask a question or spend the time to learn it on their own, then of course they are not going to make much progress with overcoming those package management issues they have. It would seem to me though, that there is plenty of access to experienced julia developers on discourse… and opening up a topic here is that lottery ticket for help.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [September 25, 2019, 8:57am UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/13 "2019-09-25T08:57:58Z")
> [@chakravala](#):
>
> Rejecting a request for making a 1.0 tag would not automatically generalize to it being unmaintained.
Just to clarify: I meant this for packages which are otherwise pretty stable and can be considered “mature”, if unfinished.
---
### Author:  [@Tero\_Frondelius](https://discourse.julialang.org/u/Tero_Frondelius)
#### Post date: [September 25, 2019, 10:01am UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/14 "2019-09-25T10:01:42Z")
> [@oxinabox](#):
>
> Otherrs are not tagged 1.0 because they entered defacto stability, without concious effort on my part.
> They just stopped having things I needed to change in them.
I think these are the packages one could easily tag v1.0.0 to them. I believe these are the major part of the packages this thread is all about. Some small stabilized package that are widely in use, but not under active development because they are ready enough.
---
### Author:  [@anon92994695](https://discourse.julialang.org/u/anon92994695)
#### Post date: [September 25, 2019, 10:30am UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/15 "2019-09-25T10:30:00Z")
Hm yea maybe the lottery idea isn’t very good I was just spit balling. But what I mean is, the easier we can make it (improving docs, tutorials, etc) to stand up a package the more effort we’ll see (I think). Back when I was setting up my package, half the tutorials weren’t around and I had to message maybe 3-4 people on here who helped me out. That’s a bit of effort, and people working for free may be less motivated to go that far to solve a problem. I’ve asked for help for things like this and gotten silence a few times. There are still dev ops things like this that I want to do but don’t know how to, and I haven’t been able to find adequate Docs/tutorials to help me.
We can’t expect people to visit and help build a community if the draw bridge is raised and the castle door is shut some of the time. Not everyone wants to swim across a moat to scale a wall to donate effort met with critical reception in their free-time. The soft-ware/dev ops side of things is not trivial for a lot of people. It takes a lot of time, and a bit of it is Julia specific. I think we can ameliorate some of it with tooling, documentation, and community support.
---
### Author:  [@oxinabox](https://discourse.julialang.org/u/oxinabox)
#### Post date: [September 25, 2019, 10:32am UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/16 "2019-09-25T10:32:11Z")
I have proposed this before,
but the seperation of General into Bazaar and Cathedral.
Where current General is Bazaar.
Fairly low checks before adding things.
Even things v0.0.1 are present, and may be abandonned without more than a single release.
Then we can have Cathedral,
Requires v1.0.0,
requires having had a few releases in Bazaar,
can only have Cathedral dependencies.
must have CI working and sensible tests.
Getting into Cathedral would presure people to firm APIs up to be able to tag 1.0.
Most people can be happy with Bazaar, but certain things that need a bit more reliability
(e.g. Registrator) might decide to only use the Cathedral registry.
---
### Author:  [@anon92994695](https://discourse.julialang.org/u/anon92994695)
#### Post date: [September 25, 2019, 10:36am UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/17 "2019-09-25T10:36:04Z")
I like the idea of making a distinction between packages, but I don’t think this would help the problem? If anything it may be more defeating to hobby developers.
> [@oxinabox](#):
>
> Getting into Cathedral would pressure people to firm APIs up to be able to tag 1.0.
Instead of words like “pressure” could we swap that out with “help”? Something like this,
> [@](#):
>
> To get into Cathedral developers would be helped to firm up APIs and be able to tag 1.0.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [September 25, 2019, 11:12am UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/18 "2019-09-25T11:12:09Z")
> [@anon92994695](#):
>
> people working for free may be less motivated to go that far to solve a problem
I have no hard data on this, but I imagine very few people here are paid to write packages, make them user-friendly, and document them nicely. People have various motivations, but not being paid (directly) is pretty much the norm for open source scientific software, so I am not sure why you emphasize this.
> [@anon92994695](#):
>
> We can’t expect people to visit and help build a community if the draw bridge is raised and the castle door is shut some of the time.
I don’t think this is a fair characterization of the status quo. Setting up a package is [well-documented](https://julialang.github.io/Pkg.jl/dev/creating-packages/), and so is [docs deployment](https://juliadocs.github.io/Documenter.jl/dev/man/hosting/), and there even some helper packages like
> **[GitHub - JuliaCI/PkgTemplates.jl: Create new Julia packages, the easy way](https://github.com/JuliaCI/PkgTemplates.jl)**
>
> Create new Julia packages, the easy way. Contribute to JuliaCI/PkgTemplates.jl development by creating an account on GitHub.
> **[GitHub - tpapp/PkgSkeleton.jl: Generate Julia package skeletons using a...](https://github.com/tpapp/PkgSkeleton.jl)**
>
> Generate Julia package skeletons using a simple template system - GitHub - tpapp/PkgSkeleton.jl: Generate Julia package skeletons using a simple template system
Of course, if after going through the process of creating a package you think the docs can be improved, just make a PR.
---
### Author:  [@anon92994695](https://discourse.julialang.org/u/anon92994695)
#### Post date: [September 25, 2019, 11:47am UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/19 "2019-09-25T11:47:22Z")
I have to admit things have gotten better over the last year or so. But there’s a lot of over-hanging knowledge with-in this area. It’s knowledge professional soft-ware developers have, and not knowledge, many specialized scientific computing people may have. A tutorial or 3, and more mature tools supported by Base Julia would be really helpful in my eyes. Especially one for TravisCI. IE how to get Travis to check all the things (docs, code coverage, etc).
I think collecting more data would help a lot - otherwise it’s just a lot of ideas. This is likely me projecting my issues onto a much larger populace. I would however be interested in any evaluation on the number of packages beyond 1.0 that were maintained, or developed by paid professionals(academics relying on it to get work done, core Julia team, etc), might be hard to track down though… Ultimately though, I think - community support is the key thing here.
---
### Author:  [@lobingera](https://discourse.julialang.org/u/lobingera)
#### Post date: [September 25, 2019, 11:52am UTC](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124/20 "2019-09-25T11:52:42Z")
In discussions like this, i get the strange feeling that people have some trust that magical things about SW stability and usability happens, if the version is set as 1.0.
Which is not the case (afaik).
So ask yourself: Which problem is solved by giving a (suitably) stable package the label 1.0?
[Next page](https://discourse.julialang.org/t/how-can-we-encourage-julia-package-developers-to-release-version-1-0-0/29124.md?page=2)