On 09.01.19 18:52, Eric Blake wrote: > On 1/9/19 11:38 AM, Max Reitz wrote: > >> >> <general whining> >> Actually, to me what you're saying sounds more like "Our deprecation >> policy is useless" to which I wholeheartedly agree. I think we should >> only remove things in major releases, and only if it was deprecated in >> the previous major release already. (So if you deprecate something in >> 4.0, you can remove it in 5.0; but if you deprecate it in 4.1, you can >> remove it only in 6.0.) From a user standpoint I really think we >> deprecate stuff too irregularly. >> </general whining> > > That's actually incorrect. Our current version numbering scheme is that > the major version number is NOT synonymous with major releases: we just > bump the major version number once per year, and ALL releases are on > equal footing with no one release being more major than others. Thus, a > policy that (at least) 2 releases is needed for a deprecation is > consistent, where one that requires waiting for a bump in the major > version number (which is as short as one release and as long as 3, given > that we bump every year with about 3 releases per year) is the one that > is less predictable and less meaningful (why is waiting for January > better than waiting for 2 releases?).
This sounds to me like we just don't have major releases because our deprecation policy doesn't make use of it. If we only broke APIs when bumping the major release number, then by definition that would be major releases, no? Also, if you %s/major release/x.0 release/g in my whining, the argument remains the same. And, yes, I dislike our versioning policy, too. My whining may have indicated that I like semver. Max
signature.asc
Description: OpenPGP digital signature
