Just to clarify: I meant this for packages which are otherwise pretty stable and can be considered “mature”, if unfinished.
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 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.
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?
It is my impression that most people here are not “professional” programmers (in the sense that they studied something like CS; this is not a comment about the quality of their code which in many cases exceeds what one would get from a “professional” programmer).
The template generator packages above set up all of this for you. I think they are really the best starting point, you can fill in the gaps and customize your setup based on this if necessary.
That from then on, various assumptions in SemVer begin to apply.
In this sense, the version number is more of a way of communicating something about prospective changes about the package, than any claims about the stability/usability/… per se.
Take, for example,
One of the oldest packages, with multiple committed maintainers, and a pretty stable API. It is still at v0.21.1. In principle, according to SemVer, 0.22 could be a small incremental change or something totally breaking. There is no way to know, so specifying a
compat bound for it does not mean much, unless you pin to the exact version.
Okay? I was expressly referencing the following clause “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)”.
In my post you’ll see I specifically mention Julia Base for hosting things like this, IE: " A tutorial or 3, and more mature tools supported by Base Julia would be really helpful in my eyes". Is a new person, really going to go scour the registry for a template generator if they didn’t know such a thing existed? However, if it were in the doc’s “Hey we have a package template generator to make life easier”, that’d be helpful…
If you’d like to see a better link to it in the docs, all you would need to do is make a pull request adding it.
Probably not, but it is not necessary. A reasonable new user will just read the Pkg docs about creating packages, or search the web for “creating Julia packages” (where the first result is the aforementioned page) or something similar, and see PkgTemplates.jl mentioned there. Or search these forums and learn about these tools, or ask here, etc.
An unreasonable new user will just keep complaining endlessly about these things, even if they are documented and can be found easily.
Nope, creating a Cathedral does not help. We should be honest with ourselves about what anything we do does.
Help implies assist.
Creating a Cathedral mostly gives develops something to aim for,
encouraging them to think about devising plans that will allow them to get there package into such a registry.
It also might indirectly help, as other people who do want to have their packages in a Cathedral registry
but want something that is not 1.0 ready as dependencies, might pitch in and help,
by doing things like triaging issues, and suggesting roadmaps.
And then working on them.
That is helping
My apologies. When I was cutting my first release, roughly a year ago, I don’t think that package was included in the Docs (or maybe it was in dev). If it was, none of the core users suggested I use it. I haven’t re-read the entirety of the docs for that section since then. I hope you don’t view what I’m saying as complaining - especially “endlessly”? I’m offering suggestions on a discourse.
In summary what I’ve said is:
Find peoples pain points -> Address them
Improve the community
All I’ve done is illustrate my pain points to try and help?
In my eyes, if there’s no difference in community involvement then there’s really no need to break packages into 2 categories. Just seems like levels in a video game or something to me.
Instead of exhorting others to do this, it may be more effective to just do this yourself.
For example, if you have experienced “pain points” in finding things in the docs, you are in the position to address them, especially as they may be overlooked by experienced users who no longer need to look up these things.
Yes let me make a survey from package maintainers regarding their pain points using Julia rather then the core developers.
How about adding a feature to pkg.julialang.org to filter for v1.0+ tags? Then if you wanted a list of packages that are only tagged as v1.0+ you could get that list easily. This would also encourage developers to transition to a 1.0 tag eventually, because it is now part of the search filter options on the
It’s good point. But I believe it’s not time yet. It can take 10 years to make a language 1.0. So do many packages, it’s just one year after Julia 1.0, I’d expect one or two more years to let developer explore experimental things and decide which point will be the long term support API.
In our own case, the quantum computing framework. We actually had a few large refactoring in last year, which is because we find there were still a lot places to improve and meanwhile we also find certain things that can be stabilized. But even so, I think our plan is to have our first 1.0 in next summer. It’s just too soon, only a few packages had enough time to get 1.0 (like JuMP, etc.) And it’s not always bad to get 1.0 a bit late.
I really like this approach to promote switching towards 1.0 versions.