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?). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature