Some observer's thoughts on developments of Julia packages and modules

General Usage
1

Recently excellent package DataFrames.jl arrived at version 1.0.0 (today it is v1.1.0), which make me wonder about time that such development takes. Complaining about not having it sooner, when you have such excellent, open, free software at your fingertips is just wicked, immoral, depraved indecent behavior, so I want to avoid it at all cost.

Since I hope that in the future I will find my niche working on some scientific project with Julia, I want to ask people that have experience with it, what are the bottlenecks in the development of Julia packages/modules, that 50% or more of Julia packages/modules stayed for many releases in 0.x.y version? Of course I maybe biased and only most packages that I use stick in this state of versioning.

To give I have Julia 1.6.1 on my computer and today I make Pkg3 up (good name?). Among 20 updates, which is quite modest number, 11 of them are in version 1.0.0 or higher after update. Few examples.

Name Version
ChainRulesCore 0.9.41
Colors 0.12.8
ColorSchemes 3.12.1
ColorTypes 0.11.0
Distributions 0.25.0
HTTP 0.9.8
StatsBase 0.33.8

This is of course “glass is half empty” view, but I’m just pondering about what I see. There is quite normal that Julia packages have version 0.20+.0+, like for StatsBase.jl. I guess Colors, ColorSchemes and ColorTypes are related, so this is odd to me that ColorSchemes is in version 3.x.y and two others in version 0.x.y. This probably mean that ColorSchemes is much simpler than two others, still this looks odd.

I have few ideas why arriving at version 1.0.0 for many Julia packages can take few dozens of 0.x.y version.

  • Not enough manpower. I guess this is probably the most important factor.
  • Julia is innovative language and we still learn how to use it. So development of any package is little research project on topic “How to make package for X in Julia way?”. I don’t know how plausible is this statement.
  • Julia community have very high standard of what should be in version 1.0.0 so they take a time to polish everything that they can.
  • Julia 1.0.0 was released in August 2018 and following 2.5 years in not enough time to allow packages ecosystem to mature.
  • We don’t have enough Chrises Rackauckases to speed up every project. Ten more are needed. :wink: :wink:

I will be grateful for your advice’s.

I don’t know if Usage is the best place for this topic, but I look at all categories and this one feel the least off.

2

v1 is arbitrary. It means that the author thinks the interface will churn less frequently

4 Likes
3

For comparison, the Pandas python package released version 0.3 in 2011 and version 1.0 in 2020.

8 Likes
4

This discussion has been had many times, including not all that long ago.

5 Likes
5

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

5 Likes
6

Thank you for pointing these out. I read quite a lot topics on this forum, but even with search there’s just too much to know and find everything, is you don’t have good keywords.

7

I know that it is arbitrary. Maybe this is effect of my being teached heavily to do everything to not break others code, that I feel deep unease when I need to use package with version 0.x.y.

Excluding situation that I’m among people that develop version 0.x.y, if being tester count as developer.

8

I understand that feeling well. I’m reluctant to update dependencies because it is often a waste of time adapting code to changed APIs.

I suppose my point was that there is no objective measure of code maturity. Following semver rules can inhibit declaring v1 for otherwise production level code.

9

For HypertextLiteral it’s helping me prioritize. I’m looking for things that I’m pretty sure I’ll need to change in the future, and being conservative about them (making them errors), or implementing a good enough approach that can be filled out without breakage till there’s enough reason to justify going to 2.0.

1 Like