This is important: there are many packages that are written in Julia 0.4, 0.5, 0.6, etc and are abandoned/unmaintained. One solution to help these packages revive is to use FemtoCleaner to removed deprecated syntax.
Apparently, Deprecations.jl can’t be used to update Julia 0.6 → 0.7 deprecations. And, in Deprecations.jl in CSUtilities, the developers have used some weird syntax for iterating (start, next, done) which is very hard to understand.
I think I can’t help much. This means any package which used Julia <0.7 specific syntax is dead and unusable. That’s why developers didn’t/couldn’t update Deprecations and FemtoCleaner.
While FemtoCleaner is (was?) a nice tool, updating old code is just a bit more time consuming, but not infeasible, without it.
FWIW, I think that for most cases, a complete rewrite/refactor is preferable to updating from 0.4, as the language changed so much since (0.5 is borderline, but I would go for a rewrite in any case). This should be easy if the package has tests, and when it doesn’t, this signals code quality issues that make a clean slate reimplementation preferable.
True, and the availability of v0.7 as a transition makes it even easier. I wonder a bit about this need to revive old projects - if they haven’t been updated, it suggests to me that they’re not needed or that the effort to accomplish the same thing had gone elsewhere.
That said, if you put in the effort to make the changes and the owner of the repo has abandoned it and won’t merge, that’s really unfortunate. I feel like I’ve seen discussions about what to do with orphaned projects w/r/t the registry, but you can always fork it and call it Great Package2 and register that.
I wonder a bit about this need to revive old projects - if they haven’t been updated, it suggests to me that they’re not needed or that the effort to accomplish the same thing had gone elsewhere.
This is not true. Julia has changed a lot just in 2-3 Years! It is not like 10 years ago that we deprecated Julia <0.7 Syntax.
Also, Julia users are not that active in the application part (compared to Python and Matlab). There are many packages that did one specific task in the past for that developer. And after some time now some other developer needs some functionality.
I would be great if there was a procedure for recycling the name for the fork of abandoned projects.
Eg an example proposal:
if a major Julia version has been released for at least 2 years and a registered package for a former version has not been updated,
an issue can be opened on the General registry, cc’ing the original developer
who can signal interest in keeping the name; if this does not happen, the package name passes to the fork (with a new UUID of course) after a 1-month waiting period (which can be skipped if the source repo is no longer available)
I’ve seen numerous proposals / discussions of this sort, but can’t find any just now. I could have sworn not all of them took place on slack…
I think this is sensible, but might even make the timeline a bit quicker.
Right. And that new developer may need to do the work to get it up to the newest version. Bless them for putting in the effort!
This is why I’m concerned about willy-nilly saying “let’s upgrade all the repos!” 5000 upgrade projects is A LOT for a volunteer brigade of coders.
And given that the slow pace of questions here and on slack asking for an old unmaintained project to get upgraded, it seems likely to me a good number of those packages aren’t needed/won’t be used, meaning that a decent chunk of that effort would be wasted.
That said, I’m not arguing against your original idea that FemtoCleaner and Deprecations get upgraded/maintained - that seems like a great idea. Since effort there can potentially scale to however many unmaintained projects actually are needed by future developers.
An additional proposal might be some way of alerting potential users of unmaintained projects that these tools exist and how to use them, but I can’t think of a good mechanism to do this, other than just telling them when they inevitably ask. Then again, as I said, the pace of this sort of thing seems slow enough that this might be the best mechanism.