RFC: should we remind people to upgrade?

Sean Farley sean.michael.farley at gmail.com
Mon Dec 31 13:43:36 CST 2012


On Mon, Dec 31, 2012 at 12:56 PM,  <paul_nathan at selinc.com> wrote:
> mercurial-devel-bounces at selenic.com wrote on 12/23/2012 12:31:32 PM:
>
>> From: Matt Mackall <mpm at selenic.com>
>> To: mercurial-devel <mercurial-devel at selenic.com>,
>> Date: 12/23/2012 12:31 PM
>> Subject: RFC: should we remind people to upgrade?
>> Sent by: mercurial-devel-bounces at selenic.com
>>
>> Something like 30% of bug reports are from people running copies of
>> Mercurial that are a year old or more and who would benefit from
>> upgrading. Perhaps we should gently remind people that their copy is
>> getting stale.
>>
> [snip]
>
> Hi Matt,
>
> As a private individual who has hg installed on something like 6-8 different
> machines, I would enjoy this kind of nice reminder to upgrade, as I like to
> stay up to date!
>
> As a "corporate consumer", where Versions Are A Big Deal, I would like the
> option to disable this; some kind of "ui.upgradereminder=no" option for hgrc
> files.
>
> Our in-house production version is 2.2.3, and while we are actually prepared
> to upgrade "real soon now" at this point in time (waiting on a thg deb at
> the moment), our plan is to tick over our in-house client hg versions about
> once per six months and our server hg versions about once per year. It would
> be terribly frustrating having to explain to everyone that yes, they are out
> of date, no, they shouldn't go out of sync, etc. Part of my goal is to
> ensure that our internal extensions and tools will not break on upgrade;
> another part of my goal is to balance upgrade speed with disruption to our
> work schedules. So we will be delaying upgrades on a routine basis to ensure
> a quality hg experience for our users.  I anticipate that this requirement
> set is not unique to SEL.

I think the whole point of this, if I understand correctly, is to only
print the "your version is not the newest" message in a backtrace
(i.e. something is definitely breaking) which seems fine for corporate
and private users alike.


More information about the Mercurial-devel mailing list