# Classifiers - Development Status for packages

**URL:** <https://discourse.julialang.org/t/classifiers-development-status-for-packages/88722>\
**Category:** General Usage\
**Created:** [October 14, 2022, 10:15am UTC](https://discourse.julialang.org/t/classifiers-development-status-for-packages/88722 "2022-10-14T10:15:41Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 14, 2022, 10:15am UTC](https://discourse.julialang.org/t/classifiers-development-status-for-packages/88722/1 "2022-10-14T10:15:41Z")

</div>

There are basically no requirements to register a Julia package (and I believe that’s a good thing), besides having an OSI-approved license. I do see for Python, in PyPI there’s (and I suggest the same for Julia):

- 1 - Planning
- 2 - Pre-Alpha
- 3 - Alpha
- 4 - Beta
- 5 - Production/Stable
- 6 - Mature
- 7 - Inactive

E.g.

> **[julia](https://pypi.org/project/julia/)**
>
> Julia/Python bridge with IPython support.

is at [3 - Alpha](https://pypi.org/search/?c=Development+Status+%3A%3A+3+-+Alpha) (isn’t that too pessimistic, and needs to be updated?)

while no such classifier specified for (so seemingly optional):

> **[juliacall](https://pypi.org/project/juliacall/)**
>
> Julia and Python in seamless harmony

It could be optional in Julia too, and likely needs to be unset for all existing packages. Going forward (if people feel this is a good thing, working for Python), then some level could be set by default (pre-alpha?).

I don’t know if there are any requirements for the Production/Stable tag with Python, maybe at least 1.0 version number, and that the package is documented? It’s a bit hard to judge the level of documentation, quality (more so than quantity), and level of tests. Any ideas what the requirements should be? Maybe at least a non-tiny README.md and 1+ test?

I did suggest that package names should use American English spelling for consistency in the ecosystem. That issue was closed. I feel it can at least be a recommendation.

I think it might also be good to have in packages a list of suggested other packages to use, and the REPL could suggest them on install. No requirement to add such to your package.