Quoting my comments from the earlier discussion:
IMHO, encouraging major bump too much is risky. I think it would be nice to even mention that updating timescale of major versions should be targeting at least about a year and discouraging 1.0 if they can’t foresee stability more than a few months. The emphasis on timescale is somewhat inspired by Numpy’s proposed deprecation policy which discusses update frequency of users and deprecation periods. They are not using SemVer but I think the basic idea applies. Of course, I know that not all Julia packages have to be as stable as Numpy.
Although I do admire all the effort of Julia core team to support backward compatibility based on PkgEval for all the registered packages, I find it unsatisfactory to call a software stable without clearly written deprecation policy. Unfortunately, it seems that the discussion JuliaLang/Juleps#51 is stalled.
Without
juliaitself having clear deprecation policy, there is no clear reference point for Julia package authors to understand what it means to be 1.0.Another reason to avoid recommending 1.0 prematurely is that there is no clear definition of public API (I discussed it briefly in Julia's Release Process - #8 by tkf and Julia's Release Process - #14 by tkf)