Patchwork RFC: should we remind people to upgrade?

login
register
mail settings
Submitter Matt Mackall
Date Dec. 23, 2012, 8:31 p.m.
Message ID <1356294692.6482.558.camel@calx>
Download mbox | patch
Permalink /patch/279/
State Deferred
Delegated to: Matt Mackall
Headers show

Comments

Matt Mackall - Dec. 23, 2012, 8:31 p.m.
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.

Here's one way to do that:

- check the timestamp on __version__.py
- if > 6 months, report in 'hg version' and tracebacks

        $ touch -d "dec 1 2011" mercurial/__version__.py
        $ hg version
        Mercurial Distributed SCM (version 2.4.1+64-1c0dfd5f1357+20121222)
         please upgrade!
        (see http://mercurial.selenic.com for more information)
        
        Copyright (C) 2005-2012 Matt Mackall and others
        This is free software; see the source for copying conditions. There is NO
        warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This has the advantage of not needing any sort of 'phone home' mechanism
nor pestering people for whom Mercurial is working just fine. If we
deploy this in 2.5, it'll start reminding people around 2.7. Thoughts?
Idan Kamara - Dec. 23, 2012, 10:38 p.m.
On Sun, Dec 23, 2012 at 10:31 PM, Matt Mackall <mpm at selenic.com> wrote:
>
> 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.
>
> Here's one way to do that:
>
> - check the timestamp on __version__.py
> - if > 6 months, report in 'hg version' and tracebacks
>
>         $ touch -d "dec 1 2011" mercurial/__version__.py
>         $ hg version
>         Mercurial Distributed SCM (version 2.4.1+64-1c0dfd5f1357+20121222)
>          please upgrade!
>         (see http://mercurial.selenic.com for more information)
>
>         Copyright (C) 2005-2012 Matt Mackall and others
>         This is free software; see the source for copying conditions.
> There is NO
>         warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
>
> This has the advantage of not needing any sort of 'phone home' mechanism
> nor pestering people for whom Mercurial is working just fine. If we
> deploy this in 2.5, it'll start reminding people around 2.7. Thoughts?

I like it. Perhaps the warning on tracebacks should be more
visible and come earlier than the one pointing them to the
bug tracker, asking to upgrade and retry or report it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20121224/31523e6e/attachment.html>
Mads Kiilerich - Dec. 24, 2012, 12:43 a.m.
Matt Mackall wrote, On 12/23/2012 09:31 PM:
> 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.

I guess something could be achieved simply by rephrasing

   ** unknown exception encountered, please report by visiting
   ** http://mercurial.selenic.com/wiki/BugTracker

to something like

   ** unknown exception encountered, please
   ** make sure you are using the latest Mercurial version, then
   ** visit http://mercurial.selenic.com/wiki/BugTracker to find
   ** an existing bug report or file a new one

- and perhaps only show the bug tracker info if the Mercurial version is 
sufficiently recent (and no external extensions are enabled).

Some automatic "please update" message might be fine, but the 6 months 
grace perios seems a bit arbitrary. It could perhaps just as well be one 
month or less.

It would perhaps also help if the bugtracker made it more easy to search 
for closed issues.

/Mads
v - Dec. 24, 2012, 8:51 a.m.
Mads Kiilerich wrote
> Some automatic "please update" message might be fine, but the 6 months 
> grace perios seems a bit arbitrary. It could perhaps just as well be one 
> month or less.

6 months == 2 releases



--
View this message in context: http://mercurial.808500.n3.nabble.com/RFC-should-we-remind-people-to-upgrade-tp3996327p3996356.html
Sent from the Development mailing list archive at Nabble.com.
Augie Fackler - Dec. 24, 2012, 6:18 p.m.
On Dec 24, 2012, at 3:51 AM, v <voldermort at hotmail.com> wrote:

> Mads Kiilerich wrote
>> Some automatic "please update" message might be fine, but the 6 months 
>> grace perios seems a bit arbitrary. It could perhaps just as well be one 
>> month or less.
> 
> 6 months == 2 releases

Sure, but I'd rather only grouch at people when they get a traceback - complaining on every tool invocation seems excessive.

> 
> 
> 
> --
> View this message in context: http://mercurial.808500.n3.nabble.com/RFC-should-we-remind-people-to-upgrade-tp3996327p3996356.html
> Sent from the Development mailing list archive at Nabble.com.
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
Matt Mackall - Dec. 24, 2012, 6:32 p.m.
On Mon, 2012-12-24 at 13:18 -0500, Augie Fackler wrote:
> On Dec 24, 2012, at 3:51 AM, v <voldermort at hotmail.com> wrote:
> 
> > Mads Kiilerich wrote
> >> Some automatic "please update" message might be fine, but the 6 months 
> >> grace perios seems a bit arbitrary. It could perhaps just as well be one 
> >> month or less.
> > 
> > 6 months == 2 releases
> 
> Sure, but I'd rather only grouch at people when they get a traceback - complaining on every tool invocation seems excessive.

My theory is that people don't run 'hg version' much unless they're
already wondering 'should I upgrade?'
Augie Fackler - Dec. 24, 2012, 6:33 p.m.
On Dec 24, 2012, at 1:32 PM, Matt Mackall <mpm at selenic.com> wrote:

> On Mon, 2012-12-24 at 13:18 -0500, Augie Fackler wrote:
>> On Dec 24, 2012, at 3:51 AM, v <voldermort at hotmail.com> wrote:
>> 
>>> Mads Kiilerich wrote
>>>> Some automatic "please update" message might be fine, but the 6 months 
>>>> grace perios seems a bit arbitrary. It could perhaps just as well be one 
>>>> month or less.
>>> 
>>> 6 months == 2 releases
>> 
>> Sure, but I'd rather only grouch at people when they get a traceback - complaining on every tool invocation seems excessive.
> 
> My theory is that people don't run 'hg version' much unless they're
> already wondering 'should I upgrade?'

Oh, I had missed the part of the proposal where this was only on 'hg version' - that's a good idea, and makes me wholeheartedly +1.

> 
> -- 
> Mathematics is the supreme nostalgia of our time.
> 
>
Matt Mackall - Dec. 26, 2012, 10:16 p.m.
On Mon, 2012-12-24 at 01:43 +0100, Mads Kiilerich wrote:
> Matt Mackall wrote, On 12/23/2012 09:31 PM:
> > 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.
> 
> I guess something could be achieved simply by rephrasing
> 
>    ** unknown exception encountered, please report by visiting
>    ** http://mercurial.selenic.com/wiki/BugTracker
> 
> to something like
> 
>    ** unknown exception encountered, please
>    ** make sure you are using the latest Mercurial version, then
>    ** visit http://mercurial.selenic.com/wiki/BugTracker to find
>    ** an existing bug report or file a new one
> 
> - and perhaps only show the bug tracker info if the Mercurial version is 
> sufficiently recent (and no external extensions are enabled).
> 
> Some automatic "please update" message might be fine, but the 6 months 
> grace perios seems a bit arbitrary. It could perhaps just as well be one 
> month or less.

I actually don't want to insist people update every month just for the
sake of being current. That's a lot of (distributed) work for very
little gain. If you're using 1.6.4 (Debian stable) or 1.4.3 (Ubuntu LTS
and RHEL 6) then great: you've spared yourself 20 updates and possibly
avoided some regressions and various headaches incurred by manually
installing packages.

But on the other hand, if something ISN'T working for a 1.x user today,
odds are high we've already fixed it, so a bit of forward pressure is
useful. The same won't be true of 2.3 for a while.

> It would perhaps also help if the bugtracker made it more easy to search 
> for closed issues.

Ugh, yes. Bugzilla tries to find duplicates when people file new issues,
but it's not terribly effective. And by default, closed bugs are
filtered in quick queries. Unfortunately, it's basically impossible to
Google useful information about a bug tracker, but if you can figure out
how to change the latter, I'd be interested.
Pierre-Yves David - Dec. 28, 2012, 9:39 p.m.
On 23 d?c. 2012, at 21:31, Matt Mackall wrote:

> 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.
> 
> Here's one way to do that:
> 
> - check the timestamp on __version__.py
> - if > 6 months, report in 'hg version' and tracebacks
> 
>        $ touch -d "dec 1 2011" mercurial/__version__.py
>        $ hg version
>        Mercurial Distributed SCM (version 2.4.1+64-1c0dfd5f1357+20121222)
>         please upgrade!
>        (see http://mercurial.selenic.com for more information)
> 
>        Copyright (C) 2005-2012 Matt Mackall and others
>        This is free software; see the source for copying conditions. There is NO
>        warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> This has the advantage of not needing any sort of 'phone home' mechanism
> nor pestering people for whom Mercurial is working just fine. If we
> deploy this in 2.5, it'll start reminding people around 2.7. Thoughts?

The overall idea is great. Maybe the message could be a bit longer

	This version is likely outdated, please upgrade!

The traceback version could even more verbose

	This version is likely outdated, please upgrade before reporting!
paul_nathan at selinc.com - Dec. 31, 2012, 6:56 p.m.
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. 

- - -
Regards,
Paul Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20121231/bdfd568c/attachment.html>
Sean Farley - Dec. 31, 2012, 7:43 p.m.
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.

Patch

diff -r 1c0dfd5f1357 mercurial/commands.py
--- a/mercurial/commands.py	Sat Dec 22 18:11:51 2012 -0600
+++ b/mercurial/commands.py	Sun Dec 23 14:19:06 2012 -0600
@@ -6021,6 +6021,8 @@ 
     """output version and copyright information"""
     ui.write(_("Mercurial Distributed SCM (version %s)\n")
              % util.version())
+    if util.upgradeable():
+        ui.write(_(" please upgrade!\n"))
     ui.status(_(
         "(see http://mercurial.selenic.com for more information)\n"
         "\nCopyright (C) 2005-2012 Matt Mackall and others\n"
diff -r 1c0dfd5f1357 mercurial/dispatch.py
--- a/mercurial/dispatch.py	Sat Dec 22 18:11:51 2012 -0600
+++ b/mercurial/dispatch.py	Sun Dec 23 14:19:06 2012 -0600
@@ -244,9 +244,11 @@ 
                          "please report by visiting\n") +
                        _("** http://mercurial.selenic.com/wiki/BugTracker\n"))
         warning += ((_("** Python %s\n") % sys.version.replace('\n', '')) +
-                    (_("** Mercurial Distributed SCM (version %s)\n") % myver) +
-                    (_("** Extensions loaded: %s\n") %
-                     ", ".join([x[0] for x in extensions.extensions()])))
+                    (_("** Mercurial Distributed SCM (version %s)\n") % myver))
+        if util.upgradeable():
+            warning += _("**  please upgrade!\n")
+        warning += (_("** Extensions loaded: %s\n") %
+                    ", ".join([x[0] for x in extensions.extensions()]))
         ui.warn(warning)
         raise
 
diff -r 1c0dfd5f1357 mercurial/util.py
--- a/mercurial/util.py	Sat Dec 22 18:11:51 2012 -0600
+++ b/mercurial/util.py	Sun Dec 23 14:19:06 2012 -0600
@@ -145,6 +145,16 @@ 
     except ImportError:
         return 'unknown'
 
+def upgradeable():
+    '''detect whether we're due for an upgrade'''
+    try:
+        import __version__
+        # older than 6 months?
+        t = os.stat(__version__.__file__).st_mtime
+        return t + (30 * 60 * 60 * 24 * 6) < time.time()
+    except AttributeError, OSError:
+        return False
+
 # used by parsedate
 defaultdateformats = (
     '%Y-%m-%d %H:%M:%S',