[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Copyright year displayed by command-line tools

From: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 20 Mar 2015 14:44:21 +0100

On 20.03.2015 14:33, Branko Čibej wrote:
> On 20.03.2015 14:31, Stefan Fuhrmann wrote:
>> On Fri, Mar 20, 2015 at 8:47 AM, Stefan Sperling <stsp_at_elego.de
>> <mailto:stsp_at_elego.de>> wrote:
>>
>> On Fri, Mar 20, 2015 at 08:34:00AM +0100, Branko Čibej wrote:
>> > I just noticed that we forgot to bump the displayed copyright year.
>> > Fixed in r1667941 and nominated for backport to 1.9.x, 1.8.x
>> and 1.7.x.
>> > I also vetoed the 1.7.20 and 1.8.13 releases because of the
>> wrong year
>> > ... we really shouldn't release with wrong legalese, and we already
>> > allowed 1.9.0-beta1 to slip through with that buglet.
>> >
>> > Sorry about not noticing this earlier, I realize we already
>> have enough
>> > votes tor 1.7.20 and 1.8.13; but I really think we should pull
>> these
>> > tarballs.
>> >
>> > -- Brane
>>
>> If we decide to pull these releases based on this problem, then I'm
>> against making everyone re-run tests for this. Just allow people to
>> diff the tarballs and submit a new signature based on that.
>>
>> Could we have a buildbot test for this kind of problem?
>> Should our rat-report bot (which I can't seem to locate in the maze
>> of buildbot right now) perhaps check for this?
>>
>>
>> Yes, I think we should add a simple C test calling svn_version_extended.
>> If the year differs from the actual, FAIL. Have a grace period from
>> Dec 15
>> to Jan 15. That test would act as a simple reminder.
>>
>> I'd be happy to implement it.
>
> Don't need a C test for that, just tweak the getopt tests. Haven't
> committed this yet because we might end up removing the copyright
> blurb altogether.

And anyway, I think Philip's r1667990 is a better solution. +/e/^/i//π/
for a new test.

-- Brane
Received on 2015-03-20 14:45:37 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.