So many core packages in the Julia community, such as DataFrames
are still pre-1.0 well after they have become ubiquitous. This causes a bit of confusion. Is the lack of a 1.0
a suggestion to users that they shouldn’t depend upon it for production work? What is the commitment to keep the API stable? Having so many well worn packages not put out that 1.0
tag reminds of IETF calling everything a “Request for Comments”. At some point, it’s not really a request for comments, despite the title.
This lack of clarity is an active annoyance. When I mark a dependent on DataFrames
, how should semantic versioning work? does everyone have that shared understanding? How about dependencies of DataFrames
… are their API going to be stable? This sort of low-level churn is tiring, especially when you want bug fixes and improvements, but don’t want any big breaking changes.
Stable, yet pre-1.0 packages, are even more annoying once dependent packages enter the picture. Just today, I noticed DataFrames
was somehow downgraded in a local environment. Here’s an example of what changed when asked for a newer version…
(@v1.7) pkg> status DataFrames
Status `~/.julia/environments/v1.7/Project.toml`
[a93c6f00] DataFrames v0.21.8
(@v1.7) pkg> add DataFrames@0.22
Resolving package versions...
Updating `~/.julia/environments/v1.7/Project.toml`
[134e5e36] ↓ Catlab v0.12.0 ⇒ v0.11.2
[a93c6f00] ↑ DataFrames v0.21.8 ⇒ v0.22.7
[7f904dfe] ↑ PlutoUI v0.7.1 ⇒ v0.7.6
[08abe8d2] ↓ PrettyTables v0.12.1 ⇒ v0.11.1
Updating `~/.julia/environments/v1.7/Manifest.toml`
[324d7699] ↑ CategoricalArrays v0.8.3 ⇒ v0.9.5
[134e5e36] ↓ Catlab v0.12.0 ⇒ v0.11.2
[a93c6f00] ↑ DataFrames v0.21.8 ⇒ v0.22.7
[069b7b12] ↓ FunctionWrappers v1.1.2 ⇒ v1.1.1
[d96e819e] + Parameters v0.12.2
[7f904dfe] ↑ PlutoUI v0.7.1 ⇒ v0.7.6
[2dfb63ee] ↑ PooledArrays v0.5.3 ⇒ v1.2.1
[08abe8d2] ↓ PrettyTables v0.12.1 ⇒ v0.11.1
[189a3867] ↑ Reexport v0.2.0 ⇒ v1.0.0
[3a884ed6] + UnPack v1.0.2
This is somewhat confusing to me. I guess some other package may have been keeping DataFrames
back, which was preventing me to see PlutoUI
fixes? Yet, when DataFrames
was manually upgraded, caused PrettyTables
and Catlab
to downgrade. In any case I’m kinda confused. Regardless, figuring this out seems like re-arranging deck chairs.
What exactly is the reluctance of so many to “just tag it”? One part is perfectionism… well, I get that. But there is a more technical reason for the reluctance. Once you tag v1.0
, what is the next release? In theory you’d want to do a v2.0
for the next breaking change. But, the next release probably won’t be something one would want to call production. So, once you’re at v1.0
, you’re kind of stuck. Or so it seems. Perhaps this is where the reluctance comes from?
I have a suggestion. Once you’re stable enough for a release people are actually using, get it to v1.0
. Prune the code of experimental stuff. Get documentation to release quality. Get the coverage tests up there. Tag v1.0
and… have a small party. Take a breather.
Then, go back before the prune and fork, given it another name (say MyProject2
). Then, put that project at a more respectable version number… v0.1
… that signals your willingness to move fast and break things. Work in this project for as long as needed, till it stabilizes. With a different package name, your users can even install them side-by-side. Backports are even possible. Then, once it’s stable, merge your changes into the main project, and release v2.0
.