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 pkg website.
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.
That’s true: it’s possible to automatically generate templates for Github, Travis, whatever Travis for Windows is called, and Coversomethingorother.
But once that template is filled out, it has to be maintained by hand, and the union of all those systems is a rapidly moving target. I’ve been reading Julia code that other people have published, and I’ve noticed how few of them are keeping up with that.
I think there’s plenty of scope for the CI processes to need less documentation.
The CI systems could automate a lot more by relying on Julia’s packaging conventions. The package says what operating systems and versions it supports, and Travis could just test that it works on those. It’s clear what to do with a directory called docs. In principle, the package generator could put lang: Julia in Travis.yml, that would never have to change, and Travis could fill in the rest with defaults that currently worked.
It would also be helpful for Julia to have a ContinuousIntegration package, and for package maintainers to not need to know anything else. For example, you could say, ci"start testing Foo". Assuming you had appropriate privileges on Github, that would set up whatever kinds of testing were currently recommended for the systems that package Foo claimed to support. Similarly ci"stop publishing Foo" if for whatever reason you wanted to publish the manual by hand. Only a few specialists would need to know the details of CI worked, and package maintainers could take it for granted.
I think you may be confused about how CI works currently. Eg on Travis, you just need a few lines of a .travis.yml for CI per se, something like
language: julia
os:
- linux
- osx
julia:
- 1.1
- 1.2
- nightly
and literally don’t have to do anything else. It is all automated, there is nothing else to do on the Julia side: the existing script will just instantiate packages and run your tests. So I am not sure what role the package you suggest would play.
The rest of the setup is about generating the docs and submitting coverage (for which there is a package already).
I am not sure what you mean here. In my experience, the only things to change are
bumping the pinned version of Documenter in the relevant project file and updating the setup (this can be done when I feel like it, since old versions just keep working fine — I usually do this when I want new features)
adding a new Julia version to the matrix.
it isn’t really that much to up date it most of the time.
You just want to add the new version you want to test on.
But there is an issue to allow PkgTemplate to update for you