qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 0/3] HMP/snapshot changes - do not use ID any


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH v2 0/3] HMP/snapshot changes - do not use ID anymore
Date: Fri, 11 Jan 2019 13:35:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]