[Live-demo] Enhancement for Version number in Online Documentation

[Frank Gasdorf]

Update on this:

Replacement within target URLs for images isn't possible yet. I found an
other solution but this would lead to images without links in the first
step. And here is what I plan to do:

1. enable extension "sphinx.ext.extlinks" in conf.py :

extensions = [ 'sphinx.ext.extlinks' ]


2. define an extlink for the download area in conf.py :

base_download_release_url= '
http://download.osgeo.org/livedvd/release/%(projectversion)s/%(variable)s' %
{ 'projectversion': version,'variable':'%s'}

extlinks = {

'osgeolive-download': (base_download_release_url, 'filename ')

}


3. usage in download.rst page:

[..]
   .. image:: ../images/download_buttons/download-vm.png
     :align: left

:osgeolive-download:`osgeo-live-vm.7z: <osgeo-live-vm.7z>` (|
osgeo-live-vm-7z-size|)
[..]


4. same procedure for the md5 files :

 :osgeolive-download:`osgeo-live-vm.7z.md5 <osgeo-live-vm.7z.md5>`


I would suggest to rename the files that the version number is not included
anymore. The download area has the dynamic version number taken from the
VERSION.txt file (for example:
http://download.osgeo.org/livedvd/release/%(projectversion)s/ would lead
into http://download.osgeo.org/livedvd/release/5.0/ if  VERSION.TXT has the
line "5.0" in it )

But in this case its necessary to change ISO naming procedure... Please have
a look at the patch file coming along with this mail.

pros:
 * single point to define download URL's
 * translators do not have to care about renaming
 * no version update required in rst files anymore
cons:
 * update of shell scripts required for naming of ISO and 7z as well
as md5 files
(I have no chance to try the build with patched shell scripts)
 * changes would be close to release day, maybe it's better to change after
5.0 release ...

What do you think? Any opinions?

Cheers, Frank


2011/7/7 Alex Mandel <tech_dev at wildintellect.com>

> On 07/07/2011 11:37 AM, Frank Gasdorf wrote:
> > 2011/7/7 Alex Mandel <tech_dev at wildintellect.com>
> >
> >> Frank,
> >>
> >> No there is not a deployment script which uploads the ISOs, it's much
> >> more complicated than you think since that url is actually redirected to
> >> a tool that then sorts people's downloads amongst the 5 mirrors.
> >>
> >> The url as defined by the last release will be correct for the next
> >> release.
> >> Where:
> >>
> >>
> http://download.osgeo.org/livedvd/release/[version]/osgeo-live-[version].iso
> >>
> >>
> >>
> http://download.osgeo.org/livedvd/release/[version]/osgeo-live-mini-[version].iso
> >>
> >>
> >>
> http://download.osgeo.org/livedvd/release/[version]/osgeo-live-vm-[version].7z
> >>
> >> End up as:
> >> http://download.osgeo.org/livedvd/release/5.0/osgeo-live-5.0.iso
> >>
> >> I'll just have to remember to stick to that naming convention when I'm
> >> making new versions
> >>
> >
> > Correct me, when I'm wrong, I understood, that there is an naming
> convention
> > and if we use a pattern like the version replacement, we could change the
> > download.rst files in the way you summarized. So we don't have to care
> about
> > it in the future except the naming convention or uploading area will
> change.
> >
> > Give me a go and I can update the download.rst files ...
> >
> > Cheers,
> > Frank
> >
> >
> >
> Yes go ahead and make the change to create the links dynamically. Those
> are the correct naming conventions we intend to use. The url is unlikely
> to change in the foreseeable future aside from a new folder for each
> version (which is accounted for in your method).
>
> Thanks,
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/osgeolive/attachments/20110809/3905321d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sh-iso-filename.patch
Type: application/octet-stream
Size: 2598 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/osgeolive/attachments/20110809/3905321d/attachment.obj>