For the overwhelming majority of Julia packages registered in the General registry, 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?
A blog post on the Julia 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 (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.
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?
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.
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 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.
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 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.
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 hypothesised).
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:
* < 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.
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.
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!
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
Instead of words like “pressure” could we swap that out with “help”? Something like this,
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.
I don’t think this is a fair characterization of the status quo. Setting up a package is well-documented, and so is docs deployment, and there even some helper packages like
Of course, if after going through the process of creating a package you think the docs can be improved, just make a PR.
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.
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?
