From: Peter Korsgaard <peter@korsgaard.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 0/5] legacy: drop old options (branch yem/drop-old-legacy)
Date: Mon, 29 Mar 2021 10:04:33 +0200 [thread overview]
Message-ID: <877dlqgzce.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <378607bf-548e-feec-a7b9-182bb6c50989@mind.be> (Arnout Vandecappelle's message of "Mon, 29 Mar 2021 08:59:00 +0200")
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
Hi,
> Absolutely. I recently did an update from 2018.02 to 2021.02 for a user whom I
> think is relatively conscientious about updating. So two years is definitely too
> short.
:/
> (As an aside: there's a good reason to not update too often, and that is that
> some projects sometimes dramatically break compatibility. In my case, it's the
> Phalcon PHP package - it took me three days to fix all the breakage in the
> custom PHP scripts using that package, and I'm still not sure it's all good.)
I would argue that this is exactly a reason for updating MORE often than
less, to make the delta smaller and easier to debug. Doing it often
makes you also more inclined to automate it and write some decent
regression tests.
The best solution is naturally to not build your product on top of such
moving targets in the first place, but you don't always have to option
to do so.
>>> Since the maintenance cost of those legacy options is essentially zero,
>>> I am wondering if we really need to drop them. Should we change the
>>> rule and drop the ones that are 5 years old for example ?
> Indeed. I always thought that the idea was that we would keep the legacy around
> until there was some reason to remove them, but that we'd advertise some fixed
> period to make sure people are not surprised about the removal.
I am also fine with 5 years (or even more, as long as they don't get in
the way).
--
Bye, Peter Korsgaard
prev parent reply other threads:[~2021-03-29 8:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-27 20:53 [Buildroot] [PATCH 0/5] legacy: drop old options (branch yem/drop-old-legacy) Yann E. MORIN
2021-03-27 20:53 ` [Buildroot] [PATCH 1/5] legacy: add note about removing options Yann E. MORIN
2021-03-27 20:53 ` [Buildroot] [PATCH 2/5] legacy: drop options more than 5 years old Yann E. MORIN
2021-03-27 20:53 ` [Buildroot] [PATCH 3/5] legacy: drop options more than 4 " Yann E. MORIN
2021-03-27 20:53 ` [Buildroot] [PATCH 4/5] legacy: drop options more than 3 " Yann E. MORIN
2021-03-27 20:53 ` [Buildroot] [PATCH 5/5] legacy: drop options more than 2 " Yann E. MORIN
2021-03-28 19:24 ` [Buildroot] [PATCH 0/5] legacy: drop old options (branch yem/drop-old-legacy) Thomas Petazzoni
2021-03-28 19:52 ` Yann E. MORIN
2021-03-29 6:59 ` Arnout Vandecappelle
2021-03-29 8:04 ` Peter Korsgaard [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=877dlqgzce.fsf@dell.be.48ers.dk \
--to=peter@korsgaard.com \
--cc=buildroot@busybox.net \
/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