Closed
Bug 335594
Opened 14 years ago
Closed 14 years ago
Make Sunbird release notes URL not include version number
Categories
(Calendar :: Sunbird Only, defect)
Calendar
Sunbird Only
Not set
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mattwillis, Assigned: mattwillis)
References
Details
Attachments
(1 file, 1 obsolete file)
8.32 KB,
patch
|
jminta
:
first-review+
sipaq
:
second-review+
|
Details | Diff | Splinter Review |
We shouldn't have to bump the version number in a dtd each time we release simply to update the release notes URL. We can find our version number. Use that!
Assignee | ||
Comment 1•14 years ago
|
||
Release notes URLs would then look like http://www.mozilla.org/projects/calendar/releases/sunbird0.3a2.html sipaq: You're copied so you know about this patch, and so you can comment on the proposed URL format
Attachment #219938 -
Flags: second-review?
Attachment #219938 -
Flags: first-review?(jminta)
Assignee | ||
Updated•14 years ago
|
Attachment #219938 -
Flags: second-review? → second-review?(mvl)
Assignee | ||
Updated•14 years ago
|
Blocks: calendar-0.3
Comment 2•14 years ago
|
||
Comment on attachment 219938 [details] [diff] [review] rev0 - Migrates to a release notes url generated from the version number + +# Release notes URL +releaseNotesURL=http://www.mozilla.org/projects/calendar/releases/sunbird%S.html At the very least, we need a giant DO NOT TRANSLATE sign here. I'm afraid l10n teams might try to point this to localized sunbird websites, but we probably want to maintain stricter controller over release notes than that. Don't we have a brand.properties that the URL can go in? Shouldn't it go there? + var relnotesURL = calendarBundle.getFormattedString("releaseNotesURL", + [appInfo.version]); + launchBrowser(relnotesURL); +} + + // Can you lose the extra space? - -<!-- LOCALIZATION NOTE (releaseBaseURL): The about: page appends __MOZ_APP_VERSI -ON__.html, e.g. 2.0.html --> -<!ENTITY releaseBaseURL "http://www.mozilla.org/projects/calendar/releases/sunbird/"> Why are we removing this? Since this is in 'Other licenses', don't we want people repackaging Sunbird to change this? How does this patch interact with the other licenses stuff?
Assignee | ||
Comment 3•14 years ago
|
||
(In reply to comment #2) > (From update of attachment 219938 [details] [diff] [review] [edit]) > + > +# Release notes URL > +releaseNotesURL=http://www.mozilla.org/projects/calendar/releases/sunbird%S.html > At the very least, we need a giant DO NOT TRANSLATE sign here. I'm afraid l10n > teams might try to point this to localized sunbird websites, but we probably > want to maintain stricter controller over release notes than that. Don't we > have a brand.properties that the URL can go in? Shouldn't it go there? We could put it there instead. I put it where Firefox has it, but brand.properties also sounds like a valid and good place. > > + var relnotesURL = calendarBundle.getFormattedString("releaseNotesURL", > + [appInfo.version]); > + launchBrowser(relnotesURL); > +} > + > + > // > Can you lose the extra space? Sure. Which one? > > - > -<!-- LOCALIZATION NOTE (releaseBaseURL): The about: page appends > __MOZ_APP_VERSI > -ON__.html, e.g. 2.0.html --> > -<!ENTITY releaseBaseURL > "http://www.mozilla.org/projects/calendar/releases/sunbird/"> > Why are we removing this? Because after adding the openReleaseNotes() method, we no longer use this entity. It is then only found in the default toolkit about dialog, which we override with our own. > Since this is in 'Other licenses', don't we want > people repackaging Sunbird to change this? How does this patch interact with > the other licenses stuff? See about. It's now obsolete and doesn't need to be here. However that does bring up a good point. Since in a split branding world, brand.properties appears in two locations, we may want to keep the base release notes URL where it is so it's not in two places. On the other hand, we may want it in brand.properties so that official releases point to the notes, while generic builds point to somewhere more general, like w.m.o/projects/calendar Thanks for the good questions!
Status: NEW → ASSIGNED
Comment 4•14 years ago
|
||
With the current URL schema, this will break the 0.3a2 release notes link immediately after checkin. If everyone agrees on the URL schema, I will have to add a URL redirect shortly before checkin.
Assignee | ||
Comment 5•14 years ago
|
||
(In reply to comment #4) > With the current URL schema, this will break the 0.3a2 release notes link > immediately after checkin. This would land post-0.3a2
Comment 6•14 years ago
|
||
(In reply to comment #5) >> With the current URL schema, this will break the 0.3a2 release notes link >> immediately after checkin. > > This would land post-0.3a2 Ok, then you will break the 0.3a2 release notes for all nightlies after 0.3a2 :-)
Assignee | ||
Comment 7•14 years ago
|
||
(In reply to comment #6) > Ok, then you will break the 0.3a2 release notes for all nightlies after 0.3a2 Correct. However won't the nightlies have a non-0.3a2 version number anyway? Also, if we move to split branding, we could have nightlies use a more generic url, like the project website or something.
Comment 8•14 years ago
|
||
(In reply to comment #7) >> Ok, then you will break the 0.3a2 release notes for all nightlies after 0.3a2 > > Correct. However won't the nightlies have a non-0.3a2 version number anyway? In the past we have waited a few weeks before rebranding the nightlies, but that is probably not set in stone. > Also, if we move to split branding, we could have nightlies use a more generic > url, like the project website or something. That would be great. This will relieve me from constantly adding URL redirects.
Assignee | ||
Comment 9•14 years ago
|
||
The string stays in branding, so it can be different for nightlies versus releases.
Attachment #219938 -
Attachment is obsolete: true
Attachment #224148 -
Flags: first-review?(jminta)
Attachment #219938 -
Flags: second-review?(mvl)
Attachment #219938 -
Flags: first-review?(jminta)
Comment 10•14 years ago
|
||
Comment on attachment 224148 [details] [diff] [review] rev1 - Refinement of rev0. string is kept within branding r=jminta, but let's get sipaq to sign off too since he has to deal with all this when it lands.
Attachment #224148 -
Flags: second-review?(bugzilla)
Attachment #224148 -
Flags: first-review?(jminta)
Attachment #224148 -
Flags: first-review+
Comment 11•14 years ago
|
||
Comment on attachment 224148 [details] [diff] [review] rev1 - Refinement of rev0. string is kept within branding r=sipaq
Attachment #224148 -
Flags: second-review?(bugzilla) → second-review+
Assignee | ||
Comment 12•14 years ago
|
||
rev1 checked in on trunk and MOZILLA_1_8_BRANCH -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•