FillArrays.jl that has 99 direct dependents and 1542 indirect dependents is going to v1.0, and most of the changes are already included in the release-1.0 branch (see the changes vs master). It’s unlikely to be breaking for most users, but please have a look in case this concerns you, and in case you’d like to suggest last-minute changes.
10 Likes
Is there a changelog with the changes to help people upgrade?
Dang I always forget about cool packages like this
1 Like
Not that I know of, but this is more of a “this has been stable for a while, so let’s go to 1.0” tag, and it’s unlikely that anything needs upgrading. The way to track changes is really the commit history.
Please don’t tag breaking releases if they aren’t actually breaking.
6 Likes
Wouldn’t that keep packages from going to 1.0?
1 Like
Indeed. What’s the point?
Yes. But why do you want to go 1.0?
One advantage is having the patch version field. But one could wait until a breaking change actually merits it and jump from (say) 0.19 to 1.0.
Alternatively, in retrospective one could have registered the package starting at 1.0.
But inflicting 1.0 without needing to do so means ALL downstream packages have to update their compat. Think there are some packages out there whose maintainer will not look at the repo for months, or more.
1 Like
No, because then when you do your breaking update to change it to v1.0. Why make work for 100 other people just for a nice number? Also, you’re keeping the package from getting this update because now if anybody in the entireity of the Julia ecosystem is using FillArrays and doesn’t do the compat upgrade (which is exponentially more true the more used a package is), then nobody can use the upgrade. Therefore, for the next few months, or most likely a year for something like FillArrays, all patches will have spotty usage as some downstream package will be blocking it. 
It’s not a fun position to be in.
I would just note the following provision of semantic versioning.
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
That said, maybe it’s worthwhile to also continue to publish a 0.y.z branch for a while while also building out the 1.0 series?
3 Likes
36 posts were split to a new topic: Encouraging 1.x versions for registered packages?