Patchwork RFC: should we remind people to upgrade?

login
register
mail settings
Submitter arne_bab at web.de
Date Dec. 28, 2012, 1:24 p.m.
Message ID <1484712.3zYn3SALqi@fluss>
Download mbox | patch
Permalink /patch/317/
State Deferred
Headers show

Comments

arne_bab at web.de - Dec. 28, 2012, 1:24 p.m.
Am Sonntag, 23. Dezember 2012, 14:31:32 schrieb Matt Mackall:
> 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.

I don?t like relying on the timestamp. There are too many ways that it could 
change without affecting mercurial in any other way.

Since we?re on a timebased scheme, it would be easy to reconstruct the 
creation date directly from the version string, so the shortcut through the 
timestamp looks like a brittle hack to me.

Reconstructing the assumed current version from the version string would also 
document the release plan in code.

I would propose the following:



Changing to a new release scheme should be easy, since the releasedate 
function works strictly forward.

Best wishes,
Arne
--
Konstruktive Kritik: 

- http://draketo.de/licht/krude-ideen/konstruktive-kritik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20121228/88527fd1/attachment.pgp>
Steve Borho - Dec. 28, 2012, 6:25 p.m.
On Fri, Dec 28, 2012 at 7:24 AM, Arne Babenhauserheide <arne_bab at web.de>wrote:

> Am Sonntag, 23. Dezember 2012, 14:31:32 schrieb Matt Mackall:
> > 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.
>
> I don?t like relying on the timestamp. There are too many ways that it
> could
> change without affecting mercurial in any other way.
>
> Since we?re on a timebased scheme, it would be easy to reconstruct the
> creation date directly from the version string, so the shortcut through the
> timestamp looks like a brittle hack to me.
>

FWIW: I have doubts that Python will be able to get a time stamp from the
frozen packages that are common on Windows, and so I would prefer an
alternative approach as well

<snip>
Matt Mackall - Dec. 28, 2012, 9:17 p.m.
On Fri, 2012-12-28 at 14:24 +0100, Arne Babenhauserheide wrote:
> Am Sonntag, 23. Dezember 2012, 14:31:32 schrieb Matt Mackall:
> > 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.
> 
> I don?t like relying on the timestamp. There are too many ways that it could 
> change without affecting mercurial in any other way.

That's actually fine as this is simply an advisory heuristic. People's
clocks can also be off by decades; also not a problem.

But keying off the version number is fine.. until we decide to change
the release scheme. We will eventually do that, simply due to project
maturity. I envision us hitting that point in another 3-5 years. It
might be better to just build a timestamp into __version__.py; my first
version did just that.
Pierre-Yves David - Dec. 28, 2012, 9:37 p.m.
On 28 d?c. 2012, at 14:24, Arne Babenhauserheide wrote:

> Am Sonntag, 23. Dezember 2012, 14:31:32 schrieb Matt Mackall:
>> 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.
> 
> I don?t like relying on the timestamp. There are too many ways that it could 
> change without affecting mercurial in any other way.
> 
> Since we?re on a timebased scheme, it would be easy to reconstruct the 
> creation date directly from the version string, so the shortcut through the 
> timestamp looks like a brittle hack to me.
> 
> Reconstructing the assumed current version from the version string would also 
> document the release plan in code.
> 
> I would propose the following:

Using the date of the lastest tag could work too.
arne_bab at web.de - Dec. 29, 2012, 2:08 a.m.
Am Freitag, 28. Dezember 2012, 15:17:32 schrieb Matt Mackall:
> That's actually fine as this is simply an advisory heuristic. People's
> clocks can also be off by decades; also not a problem.
> 
> But keying off the version number is fine.. until we decide to change
> the release scheme.

The change for that would not be hard: It will only affect future versions, so 
the change can be done when the release plan changes.

Still, see my answer to Pierre.

Best wishes,
Arne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20121229/1f54fa3a/attachment.pgp>
arne_bab at web.de - Dec. 29, 2012, 2:08 a.m.
Am Freitag, 28. Dezember 2012, 22:37:10 schrieb Pierre-Yves David:
> Using the date of the lastest tag could work too.

That sounds even better - if it?s baked explicitely into __version__.py at 
release time.

Best wishes,
Arne
--
Konstruktive Kritik: 

- http://draketo.de/licht/krude-ideen/konstruktive-kritik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20121229/2403255a/attachment.pgp>
Sean Farley - Dec. 29, 2012, 2:10 a.m.
On Fri, Dec 28, 2012 at 8:08 PM, Arne Babenhauserheide <arne_bab at web.de> wrote:
> Am Freitag, 28. Dezember 2012, 15:17:32 schrieb Matt Mackall:
>> That's actually fine as this is simply an advisory heuristic. People's
>> clocks can also be off by decades; also not a problem.
>>
>> But keying off the version number is fine.. until we decide to change
>> the release scheme.
>
> The change for that would not be hard: It will only affect future versions, so
> the change can be done when the release plan changes.
>
> Still, see my answer to Pierre.

Actually, his name is Pierre-Yves. Just fyi.
arne_bab at web.de - Dec. 29, 2012, 2:57 a.m.
Am Freitag, 28. Dezember 2012, 20:10:24 schrieb Sean Farley:
> Actually, his name is Pierre-Yves. Just fyi.

Ah, sorry. I sometimes have trouble recognizing double first names.
I?ll try to remember it.

Thanks!

Best wishes,
Arne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20121229/c7bbfea1/attachment.pgp>

Patch

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -5950,6 +5950,8 @@  def version_(ui):
     """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 --git a/mercurial/dispatch.py b/mercurial/dispatch.py
--- a/mercurial/dispatch.py
+++ b/mercurial/dispatch.py
@@ -244,9 +244,11 @@  def _runcatch(req):
                          "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 --git a/mercurial/util.py b/mercurial/util.py
--- a/mercurial/util.py
+++ b/mercurial/util.py
@@ -145,6 +145,40 @@  def version():
     except ImportError:
         return 'unknown'
 
+def releasedate(version):
+    """Return the date of the given version following the time-based
+    release plan
+
+    >>> releasedate("2.4.2 more stuff")
+    (2013, 1, 1)
+    >>> releasedate("2.6")
+    (2013, 5, 1)
+    """
+    basedate240 = datetime.datetime(2012, 11, 1)
+    versiondate = version.split()[0].split(".")
+    try:
+        major, minor, point = [int(i) for i in versiondate[:3]]
+    except ValueError:
+        major, minor = [int(i) for i in versiondate[:2]]
+        point = 0
+    dmonths = (major - 2) * 30 + minor * 3 + point - 12 # 2.0 to 2.4 omitted
+    months = basedate240.month + dmonths
+    year = basedate240.year + (months - 1) // 12
+    return year, (months - 1) % 12 + 1, basedate240.day
+
+def versionagedays(version):
+    """Return the age of the current version."""
+    age = datetime.datetime(*releasedate(version)) - datetime.curdate()
+    return age.days
+
+def upgradeable():
+    '''detect whether we're due for an upgrade'''
+    try:
+        import __version__
+        return versionagedays(__version__.version) // 30 > 6
+    except AttributeError:
+        return False
+
 # used by parsedate
 defaultdateformats = (
     '%Y-%m-%d %H:%M:%S',