qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Max Reitz <mreitz@redhat.com>,
	armbru@redhat.com,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	qemu-devel@nongnu.org, muriloo@linux.ibm.com,
	dgilbert@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 0/3] HMP/snapshot changes - do not use ID anymore
Date: Wed, 9 Jan 2019 20:00:53 +0100	[thread overview]
Message-ID: <20190109190053.GM4867@localhost.localdomain> (raw)
In-Reply-To: <b8cc5195-d8f7-d971-f449-fa62e434437b@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2141 bytes --]

Am 09.01.2019 um 18:52 hat Eric Blake geschrieben:
> 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.

If you restrict it to "Our deprecation policy is useless for user-facing
changes", I might agree. I think the policy is fine for stuff like QMP
where only the management layer needs to be aware of the change. We
still have problems there, but these are not problems of the policy.

> > 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?).

As someone who usually skips distro versions because he wants to have
the change and necessary adaption only once instead of two or three
times in the same timeframe, I can see some value for users in breaking
stable APIs only in defined versions.

At the same time, I can also see the value in being able to break stable
APIs without waiting for almost two years with Max' policy and bad
timing.

For software I develop I prefer the latter, for software that I use I
prefer the former. ;-)

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2019-01-09 19:08 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06 11:11 [Qemu-devel] [PATCH v2 0/3] HMP/snapshot changes - do not use ID anymore Daniel Henrique Barboza
2018-09-06 11:11 ` [Qemu-devel] [PATCH v2 1/3] block/snapshot.c: eliminate use of ID input in snapshot operations Daniel Henrique Barboza
2018-09-06 11:11 ` [Qemu-devel] [PATCH v2 2/3] block/snapshot: remove bdrv_snapshot_delete_by_id_or_name Daniel Henrique Barboza
2018-09-06 11:11 ` [Qemu-devel] [PATCH v2 3/3] qcow2-snapshot: remove redundant find_snapshot_by_id_and_name call Daniel Henrique Barboza
2018-10-08 18:13 ` [Qemu-devel] [PATCH v2 0/3] HMP/snapshot changes - do not use ID anymore Daniel Henrique Barboza
     [not found] ` <20180921122954.GD2842@work-vm>
     [not found]   ` <355a1147-c0d0-88fc-7b68-4391bab25c54@gmail.com>
2018-10-09 17:34     ` Markus Armbruster
2018-10-10  7:56       ` [Qemu-devel] [libvirt] " Peter Krempa
2018-10-11 12:06         ` Dr. David Alan Gilbert
2018-10-11 12:35           ` Peter Krempa
2019-01-09 14:10 ` [Qemu-devel] " Max Reitz
2019-01-09 14:21   ` Kevin Wolf
2019-01-09 14:27     ` Max Reitz
2019-01-09 14:48       ` Kevin Wolf
2019-01-09 14:54         ` Max Reitz
2019-01-09 15:13           ` Kevin Wolf
2019-01-09 15:25             ` Dr. David Alan Gilbert
2019-01-09 16:25             ` Markus Armbruster
2019-01-09 16:27             ` Max Reitz
2019-01-09 16:45               ` Kevin Wolf
2019-01-09 16:58                 ` Max Reitz
2019-01-09 18:19     ` Daniel Henrique Barboza
2019-01-09 16:57   ` Daniel Henrique Barboza
2019-01-09 17:05     ` Max Reitz
2019-01-09 17:20       ` Kevin Wolf
2019-01-09 17:38         ` Max Reitz
2019-01-09 17:52           ` Eric Blake
2019-01-09 19:00             ` Kevin Wolf [this message]
2019-01-11 12:35             ` Max Reitz
2019-01-09 17:55           ` Eric Blake
2019-01-09 18:51             ` Kevin Wolf
2019-01-09 19:02               ` Eric Blake
2019-01-10 11:25                 ` Kevin Wolf
2019-01-10 11:41                   ` Dr. David Alan Gilbert
2019-01-10 13:03                     ` Daniel Henrique Barboza
2019-01-10 15:11                     ` Kevin Wolf
2019-01-10 17:06                       ` Dr. David Alan Gilbert
2019-01-10 18:22                         ` Eric Blake
2019-01-11 12:14                           ` Kevin Wolf
2019-01-11 13:22                     ` Max Reitz
2019-01-11 14:33                       ` Kevin Wolf
2019-01-11 15:23                         ` Max Reitz
2019-01-09 17:32       ` Daniel Henrique Barboza
2019-01-09 17:07     ` Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190109190053.GM4867@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=danielhb413@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=muriloo@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).