Just a quick check, using the tag creation dates and what is in the file:
1.1.3
1.1.4
1.4.3
1.4.4
1.4.5
1.6.8
1.6.9
1.6.10
1.6.11
1.6.12
1.6.13
1.6.14
1.6.15
1.6.16
1.6.17
1.6.18
1.6.19
1.6.20
1.6.21
1.6.22
1.6.23
1.8.6
1.8.7
1.8.8
(I probably missed a few, as I didn't automate the matching... just the
fetching)
Were all released with a nonmatching date. I think 1.7 is the only release line
where we actually directly updated the year on the branch, the year after
release. (For 1.6.x we never updated anything)
+1 on just releasing the releases as-is.
Bert
From: Greg Stein [mailto:[email protected]]
Sent: vrijdag 20 maart 2015 09:58
To: Branko Čibej
Cc: Subversion Development
Subject: Re: Copyright year displayed by command-line tools
Daniel Berlin stated many years ago that the years associated with copyright
lines are meaningless. There is no reason to burn/re-roll just for that.
The simple fact is that if you end up in court, then what is printed to the
console has ZERO bearing (or what year is listed in a source file). The court
will look at what/when changes *actually* happened. What we state is
irrelevant. The commit logs are the important point.
So given that, what is the purpose of displaying those years? *shrug* (which
was basically his point)
-0.9 to even thinking about burning tarballs for this reason.
-g
On Fri, Mar 20, 2015 at 2:34 AM, Branko Čibej <[email protected]
<mailto:[email protected]> > 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
