It enables you to put this in your package:
@static if VERSION >= v"1.11-"
@public foo, bar
end
This works with a @public macro, but not with the public keyword, and seems like an elegant solution to make the feature backward compatible without having to add a dependency on Compat. I’d certainly use this. I’d probably also use Compat, but given the choice, I’d rather avoid the associated problems.
That is not a use case because the requirements are even higher than that. You wouldn’t use the LTS in that case, you’d just use the current version of Julia and then reinstantiate a manifest back on the same exact version of Julia. Given that the same exact version of Julia and all packages would need to be used in a replication, there’s not an advantage to the LTS over any other version. The purpose of the LTS is to be a sustained version that’s getting patched, but if you can’t use the patches, it’s no different than any other old version.
TBH, I don’t think there are many great reasons to use the LTS in this stage of Julia or at least with the current audience of Julia. Again, the purpose of an LTS is to have a stable version that is still getting patched. The reason for LTS releases is so that important bugfixes, in particular security fixes, can be updated. In this sense, you can keep an app running while accepting fundamental security updates without requiring that you do larger updates to the app. The purpose of an LTS really is then for an updatable version that is effectively in the background, something that is “just kind of there” but that you just want to keep running, but you want to accept security updates on.
If Julia is in the “foreground” to a given project and it’s not in some security scenario like a webserver where someone is looking for exploits, you can simply choose to keep the same version. You don’t need to worry about some change in OpenSSL for a script that is just solving a differential equation on your computer and never interacts with any web server. You can boot the version up from 10 years ago and know there aren’t any “security exploits”, it’s a model, not a process people are trying to interact with. These scientific codes just don’t have that kind of issue!
That doesn’t mean there shouldn’t be an LTS, we should be diligent to cultivate a community of use cases beyond science, and there are some growing frameworks that are using Julia in many non-scientific ways like Genie. A Genie app launched on a webserver would be a great use case for the LTS.
But, it’s also precisely these applications that do not really need to care about public because they are by design applications where the user is not directly interacting with Julia. So I really do not understand the issue here.
Package extensions and startup times though? Yes, those are pretty fundamental to any service because they reduce latency, so those would be pretty necessary features for the next LTS. But all of that is captured in v1.10.
A few thoughts from a part-time LTS user:
This is more ugly/awkward that I would want, but solves some problems; my ENV var idea could be adopted as plan b (at some future date, no rush), if this or other workaround doesn’t get adopted enough, i.e. if people simply (as (too many) will most likely) do “public foo”.
It least I now get why @public would be in case for this, even better would be just having to write @public foo, bar (or without the @…) and I thought why not sine this is a macro (that could imply the above), and well then it’s an added feature… so back to why not simply add public as keyword.
One other option might be do have to do Base.@public foo, and it could (and would have to to lose toe above boilerplate) be added to 1.10, since if NOT exported (i.e. then needing qualification), doesn’t conflict with semver…
I don’t mean to be rude or accusatory, only blunt:
You have asked this question (or slight variants) literally dozens of times over the past several months across many different threads and fora, and every single time the answer has been no — I truly don’t understand what you hope to gain by asking yet again
No, it will not be backported.
Because I’m trying to solve a (perceived) problem/disaster(?), in the best possible way, i.e. I care about the Julia package ecosystem, and not making life difficult for Julia (package) developers. I proposed something that doesn’t conflict with:
- Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API.
Ok, but then semver isn’t the (valid) excuse. If you think so you misunderstood me. I’m bending over backward for those that are dogmatic on semver. Semver isn’t even the be-all-and-end-all of good software development, e.g. Rick Hickey argues against it.
This topic was automatically closed after 2 days. New replies are no longer allowed.