the SDK documentation to be hosted at addons.mozilla.org
a collection of scripts used to build this documentation
SDK documentation sets
We keep documentation for every release from 1.6 onwards. The old releases contain “obsolete” notices at the top of each page that point to the corresponding page in the current release (or to the top-level page if there isn’t a corresponding page).
The doc sets are stored underneath the “sdk” directory, in a directory whose name is the version number for the release. Like this:
sdk/1.11
1.10
1.9
When we release a new version of the SDK, the contents of the sdk directory must replace the current contents of the corresponding directory on AMO: https://addons.mozilla.org/en-US/developers/docs/sdk/. The latest alias must redirect to the latest release. Requests for any other pages under that directory must redirect to the top-level page under latest:
Check that the output of obsolete.py is what you expect (files that the tool complains about should be ones that really don’t exist in the new release, and not ones that have moved but that you have forgotten to map).
Finish up
update “latest” symlink to point to the new release
test by browsing around in sdk/
git add updated mappings.txt and everything under sdk/
Mappings file purpose and structure
You don’t need to define mappings for files which haven’t moved relative to the docs root (for example, if "sdk/1.9/packages/addon-kit/page-mod.html" exists, and so does "sdk/1.11/packages/addon-kit/page-mod.html"), or if files have been removed in the latest version. You’ll typically define mappings when you’ve reorganized the doc tree in latest, so the same file is now found at a different location relative to the root.
Each line in the mappings file defines a mapping, and consists of the file’s location in the obsolete tree, followed by a space, followed by the file’s location in latest. For example, in 1.12 we’ll be moving the API reference docs, so the file at "sdk/1.11/packages/addon-kit/page-mod.html" will now be found at "sdk/1.12/modules/sdk/page-mod.html". So we will include a mappings file with entries like:
As you see, you can specify mapping for both obsolete releases in the same mappings file. You can also use wildcards, only for the release version. So the file above could be rewritten like:
This repository contains:
SDK documentation sets
We keep documentation for every release from 1.6 onwards. The old releases contain “obsolete” notices at the top of each page that point to the corresponding page in the current release (or to the top-level page if there isn’t a corresponding page).
The doc sets are stored underneath the “sdk” directory, in a directory whose name is the version number for the release. Like this:
When we release a new version of the SDK, the contents of the
sdkdirectory must replace the current contents of the corresponding directory on AMO:https://addons.mozilla.org/en-US/developers/docs/sdk/. Thelatestalias must redirect to the latest release. Requests for any other pages under that directory must redirect to the top-level page underlatest:Building the docs for a release
clean sdk directory
…. keeping only “latest” symlink
Get the old docs
get sdocs for each release using get_release.sh:
rename directories under “sdk” to remove the minor “hotfix” version, for hotfixed releases:
Build the new docs
clone the addon-sdk:
check out the RC to generate the docs from:
copy “404.md” under addon-sdk/doc/dev-guide-source
build the sdocs for latest, using –override-version to write the final version tag in:
create latest under sdk, and extract addon-sdk-docs.tgz under it.
update “mappings.txt”
See “Mappings file purpose and structure” below).
Obsolete each old release
…
Check that the output of obsolete.py is what you expect (files that the tool complains about should be ones that really don’t exist in the new release, and not ones that have moved but that you have forgotten to map).
Finish up
update “latest” symlink to point to the new release
test by browsing around in sdk/
git add updated mappings.txt and everything under sdk/
Mappings file purpose and structure
You don’t need to define mappings for files which haven’t moved relative to the docs root (for example, if
"sdk/1.9/packages/addon-kit/page-mod.html"exists, and so does"sdk/1.11/packages/addon-kit/page-mod.html"), or if files have been removed in thelatestversion. You’ll typically define mappings when you’ve reorganized the doc tree inlatest, so the same file is now found at a different location relative to the root.Each line in the mappings file defines a mapping, and consists of the file’s location in the obsolete tree, followed by a space, followed by the file’s location in
latest. For example, in 1.12 we’ll be moving the API reference docs, so the file at"sdk/1.11/packages/addon-kit/page-mod.html"will now be found at"sdk/1.12/modules/sdk/page-mod.html". So we will include a mappings file with entries like:As you see, you can specify mapping for both obsolete releases in the same mappings file. You can also use wildcards, only for the release version. So the file above could be rewritten like: