bump copyright year to 2006

RESOLVED FIXED

Status

()

Core
Build Config
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: dbaron, Assigned: preed)

Tracking

({fixed1.8.0.1, fixed1.8.1})

Trunk
x86
Linux
fixed1.8.0.1, fixed1.8.1
Points:
---
Bug Flags:
blocking1.7.13 -
blocking1.7.14 ?
blocking-aviary1.0.8 -
blocking-aviary1.0.9 ?
blocking1.9 +
blocking1.8.1 +
blocking1.8.0.1 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

12 years ago
We need to bump the copyright year from 2005 to 2006, in way too many places, on way too many branches.

I've done one part of it on the trunk, but there's way more of this than I expected and I'm not going to finish.
(Reporter)

Comment 1

12 years ago
Created attachment 207394 [details] [diff] [review]
patch for main copyrights on trunk (checked in)

This is the one patch that I've checked in (and only to the trunk).
(Reporter)

Comment 2

12 years ago
Created attachment 207395 [details] [diff] [review]
patch for reporter
(Reporter)

Comment 3

12 years ago
Created attachment 207396 [details] [diff] [review]
patch for help content
(Reporter)

Updated

12 years ago
Flags: blocking1.9a1+
Flags: blocking1.8.1+
Flags: blocking1.8.0.1+
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.8+
(Reporter)

Comment 4

12 years ago
Comment on attachment 207394 [details] [diff] [review]
patch for main copyrights on trunk (checked in)

I missed xpfe/bootstrap/macbuild/Contents/Resources/English.lproj/InfoPlist.strings in this patch.
(Assignee)

Comment 5

12 years ago
(In reply to comment #0)
> We need to bump the copyright year from 2005 to 2006, in way too many places,
> on way too many branches.
> 
> I've done one part of it on the trunk, but there's way more of this than I
> expected and I'm not going to finish.

Does it make sense to make this a make definition somewhere in config/?
(Assignee)

Comment 6

12 years ago
*** Bug 322176 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 7

12 years ago
Created attachment 207754 [details] [diff] [review]
Update copyright strings for the 1.8.0 branch

This should address all the copyright strings for Firefox, Thunderbird, and xulrunner on the MOZILLA_1_8_0_BRANCH.

It does *not* affect the copyright strings for localized help; this should likely be something that's a part of the 1.8.0.1 localization verification checklist; as I remember, copyrights don't need to be updated unless the content actually changes, and it likely will for localization, but not necessarily on this particular branch.
Assignee: nobody → preed
Status: NEW → ASSIGNED
Attachment #207754 - Flags: review?
(Assignee)

Updated

12 years ago
Attachment #207754 - Flags: review?(chase)
Attachment #207754 - Flags: review?(benjamin)
Attachment #207754 - Flags: review?
Attachment #207754 - Flags: review?(benjamin) → review+

Updated

12 years ago
Attachment #207754 - Flags: review?(chase) → review+
(Assignee)

Updated

12 years ago
Attachment #207754 - Flags: approval1.8.0.1?
Axel: are you OK with this patch? Seems like all the help changes (unnecessary? we didn't change any help) will just confuse things...
I'm not sure if my opinion really matters. Do we need to bump the copyright
for old help content?
Anyway, we're not going to take changes to help for 1.5.0.1 in l10n, so if we 
don't have to bump all copyrights, than we're safe.
If we need a automated copyright bump for l10n, there is no 2005 in arabic digits
for gu-IN and pa-IN, both of which aren't released yet.
(Assignee)

Comment 11

12 years ago
(In reply to comment #9)
> I'm not sure if my opinion really matters. Do we need to bump the copyright
> for old help content?
> Anyway, we're not going to take changes to help for 1.5.0.1 in l10n, so if we 
> don't have to bump all copyrights, than we're safe.

Just some input here on my reasoning; I bumped the en_us help for two reasons:

a) Arguably, someone could consider it (or look to it as) the entire product copyright; dbaron and I actually discussed this briefly on Friday. I don't think either of us totally buys this, but it's good to be safe... which leads me to...

2) We wanted to ensure that if the en_US help changed (which is more likely, yes?) in the 1.5.0.{1,2,3,x} releases, the copyright was already bumped.

Unlike dbaron, I was lazy with the i10n stuff, because I thought I remember you saying the help localizations weren't likely to happen in the 1.5.0.x timeframe, so since they weren't supposed to change, I didn't bother.

Having said that, is a copyright date check part of the localization checklist (is there such a thing?)
Well, except for aboutDialog.dtd there is no need for the 2005->2006 change in locales (and theoretically not for en-US either). We were hoping to avoid *any* l10n changes between 1.5 and 1.5.0.1 so that we could reuse the FIREFOX_1_5_RELEASE tag in the l10n/ tree and not have to do commits and re-tagging on that tree.

Chase, what branch/tag (in the l10n tree) are the 1.5.0.x l10n repacackaging bits pulling from? I haven't even checked to see if we tagged l10n with FIREFOX_1_5_RELEASE; I just assumed we did but it does sound like a difficult task since locales were released at various times and some aren't released yet.
We have http://wiki.mozilla.org/MozillaQualityAssurance:l10n_checklist. I do
think we should fix copyright in a bug, not in the QA process, though.

Anyway, I'm not sure how much we're going to accept on the 1.8.0 branch in terms
of l10n, but that hasn't branched yet anyway.
We will see changes on the 1.8 branch, of course.

Comment 14

12 years ago
(In reply to comment #12)
> Chase, what branch/tag (in the l10n tree) are the 1.5.0.x l10n repacackaging
> bits pulling from? I haven't even checked to see if we tagged l10n with
> FIREFOX_1_5_RELEASE; I just assumed we did but it does sound like a difficult
> task since locales were released at various times and some aren't released yet.

It is a difficult task but I plan to use the knowledge of when the respins occurred for each of the appropriate tags.  I asked Axel if he'd like me to branch l10n files for the 1.5.0.1 release (rather than reusing the 1.8 branch for those releases) and he has told me to proceed with branching.

We'll have 1.5.0.1 l10n builds soon, but since they're not blocking the RC release (we do that only in en-US), the l10n builds will probably be ready later this week.  I plan to have the branch ready later today or tomorrow.
Comment on attachment 207754 [details] [diff] [review]
Update copyright strings for the 1.8.0 branch

a=dveditz, we do need to bump the English version whether it makes l10n's life difficult or not.
Attachment #207754 - Flags: approval1.8.1+
Attachment #207754 - Flags: approval1.8.0.1?
Attachment #207754 - Flags: approval1.8.0.1+
(Assignee)

Comment 16

12 years ago
Checked in on the 1_8_0_BRANCH; I'll look into how cleanly this patch applies on the 1_8_BRANCH.
As far as I am aware, legally there is no need to bump the copyright year at all. All it _might_ mean is that copyright on the code expires in 2089 instead of 2090 or whatever. So if it's inconvenient for anyone, let's not bother on any branches, and only do it on the trunk.

Gerv
fixed1.8.0.1 per comment 16
Keywords: fixed1.8.0.1
The 1.8.0 branch patch did not fix the three strings in Camino, while the trunk patch did.
(In reply to comment #19)
> The 1.8.0 branch patch did not fix the three strings in Camino, while the trunk
> patch did.

We've taken care of the Camino changes for the 1.8.* branches ourselves.

Comment 21

11 years ago
Note that two help documentation changes got approval for the 1.8.0 branch, bug 314814 and bug 314208.
http://bonsai.mozilla.org/cvsquery.cgi?&branch=MOZILLA_1_8_0_BRANCH&dir=&file=mozilla%2Fbrowser%2Flocales%2Fen-US%2Fchrome%2Fhelp%2F&date=all

Comment 22

11 years ago
Too late for 1.0.8/1.7.13.
Flags: blocking1.7.14?
Flags: blocking1.7.13-
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.9?
Flags: blocking-aviary1.0.8-
Flags: blocking-aviary1.0.8+

Comment 23

11 years ago
This bug is confirmed in thunderbird 1.5.0.2 and firefox 1.5.0.3 italian version, other localized version may also be affected.

Comment 24

11 years ago
Comment on attachment 207396 [details] [diff] [review]
patch for help content

Firefox Help docs are already updated on 1.8 branch and trunk.
Attachment #207396 - Attachment is obsolete: true

Comment 25

11 years ago
Bug 336554 took care of the Firefox strings on the 1.8 branch.
Is there anything left to do here? I have problems lxr'ing for 2005:

http://lxr.mozilla.org/seamonkey/search?string=2005
"Unexpected returnvalue 2 from Glimpse"

Comment 26

11 years ago
This bug is still confirmed in thunderbird 1.5.0.4 and firefox 1.5.0.4 italian
version, other localized version may also be affected.

Comment 27

11 years ago
Please land this on the 1.8 branch and add the fixed1.8.1 keyword.  Thanks!
Whiteboard: [checkin needed]
All of the changes from attachment 207754 [details] [diff] [review] have already landed on the 1.8 branch, with the exception of the extensions/help changes. I think this can be called fixed1.8.1.
Keywords: fixed1.8.1
Whiteboard: [checkin needed]

Comment 29

11 years ago
German version wasn't bumbed to 2006 neither. 1.5.0.5 nightly build still shows 2005 in "About" dialoge.
No localized versions have bumped the (C) date to 2006 in the about dialog. Some even have "2004" there.

http://lxr.mozilla.org/l10n-mozilla1.8.0/search?string=copyrightText

Comment 31

11 years ago
*** Bug 346411 has been marked as a duplicate of this bug. ***

Comment 32

11 years ago
you confused me for a minute there...I had checked the bug had not been reported for Thunderbird!
(Reporter)

Comment 33

11 years ago
Note that we really want to parameterize as many of these as possible.  It'll be 2007 by the time 1.9 ships.
Flags: blocking1.9+

Comment 34

11 years ago
*** Bug 356802 has been marked as a duplicate of this bug. ***
Flags: blocking1.9a1+
(Assignee)

Comment 35

10 years ago
I kept this open to do something more intelligent in terms of centralizing the copyright date, but... I never got around to it.

Resolving fixed, but I get to file another one of these, because it's 2007.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.