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)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mattwillis, Assigned: mattwillis)

References

Details

Attachments

(1 file, 1 obsolete file)

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!
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)
Attachment #219938 - Flags: second-review? → second-review?(mvl)
Blocks: calendar-0.3
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?
(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
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.
(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
(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 :-)

(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.
(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.
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 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 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+
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.