From: John Spray <john.spray@redhat.com>
To: Joao Eduardo Luis <joao@suse.de>,
"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>,
"ceph-users@lists.ceph.com" <ceph-users@lists.ceph.com>
Subject: Re: [ceph-users] RFC: Deprecating ceph-tool commands
Date: Mon, 11 May 2015 11:33:03 +0100 [thread overview]
Message-ID: <5550855F.2000807@redhat.com> (raw)
In-Reply-To: <554D4CD8.6020809@suse.de>
On 09/05/2015 00:55, Joao Eduardo Luis wrote:
> A command being DEPRECATED must be:
>
> - clearly marked as DEPRECATED in usage;
> - kept around for at least 2 major releases;
> - kept compatible for the duration of the deprecation period.
>
> Once two major releases go by, the command will then enter the OBSOLETE
> period. This would be one major release, during which the command would
> no longer work although still acknowledged. A simple message down the
> lines of 'This command is now obsolete; please check the docs' would
> suffice to inform the user.
>
> The command would no longer exist in the next major release.
>
> This approach gives a lifespan of roughly 3 releases (at current rate,
> roughly 1.5 years) before being completely dropped. This should give
> enough time to people to realize what has happened and adjust any
> scripts they may have.
+1, this seems like a reasonable timescale, but I think the important
thing is that it's deprecated in at least one LTS release before it's
actually removed. So maybe we should just define it like that, and say
"two stable releases or one LTS release, whichever is longer". But I
guess definition of LTS is a per-downstream-vendor thing, so maybe
harder to define -- maybe the downstream part could be a guideline to
downstream packagers, that will require no work from them as long as
they are generating LTS releases on at least every other stable release.
An additional thought: it might be useful to have a "strict" flag for
processes sending commands, so that e.g. management tools in QA can set
that and fail out when they use something deprecated. Otherwise,
automated things would tend not to notice messages about deprecation.
Cheers,
John
prev parent reply other threads:[~2015-05-11 10:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 23:55 RFC: Deprecating ceph-tool commands Joao Eduardo Luis
[not found] ` <554D4CD8.6020809-l3A5Bk7waGM@public.gmane.org>
2015-05-09 0:28 ` Gregory Farnum
[not found] ` <CAC6JEv9++PqXAkPSykDzN1=7atpTZWuzAZviSY9qWkMis9JStg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-05-09 8:31 ` Joao Eduardo Luis
2015-05-09 8:57 ` Loic Dachary
[not found] ` <554DCC0C.7040000-cLsNCMjd+0JAfugRpC6u6w@public.gmane.org>
2015-05-09 15:01 ` Joao Eduardo Luis
2015-05-11 10:33 ` John Spray [this message]
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=5550855F.2000807@redhat.com \
--to=john.spray@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=ceph-users@lists.ceph.com \
--cc=joao@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.