Developers

Guilhem BONNEFILLE Rob Norris

Releasing a New Version

Import translations

Transalations are managed under Launchpad. Currently, import of translations is done manually. So, a small organization is required in order to correctly identify possible conflicts with translation updates directly made in source code (even if this never occured). The suggested solution is to use a i18n-launchpad branch, hosting only changes related to Launchpad related translations.

Here is a suggested procedure:

  • 0. (done once) create i18n-launchpad branch from a tagged commit (git checkout -b i18n-launchpad viking-1.2)
  • 1. request translation bundle from launchpad: https://translations.launchpad.net/viking/trunk/+export
  • 2. download translations with URL received by email at viking's top source directory
  • 3. run maintainer/import-launchpad.sh
  • 4. git add any new files and update the LINGUAS file appropriately
  • 5. git commit -a -m "Import Launchpad translation updates"
    • Alternatively check each .po file and only commit those with actual changes (as all .po files will change but only with Export-Date changes and maybe Launchpad version difference).
    • To find files with more than a couple of lines of change: e.g.

      for x in `ls po/*.po`; do if [ $(git diff $x | wc -l) -gt 15 ]; then echo $x; fi ; done

  • 6. Update po/ChangeLog with content from: git show | sh maintainer/git-diff2po_ChangeLog.sh

    git show | sh maintainer/git-diff2po_ChangeLog.sh > po/tmp ; cat po/ChangeLog >> po/tmp ; mv po/tmp po/ChangeLog

  • 7. git commit -m "Document previous translation updates" po/ChangeLog
    • Alternatively use something like git gui and amend last commit to make an atomic commit of .po changes and the Changelog update with a suitable comment
  • 8. git checkout master ; git merge i18n-launchpad
  • 9. Release
  • 10. Update launchpad with new viking.pot:

    cd po ; make viking.pot

That's all.

Note: it would be certainly better to configure Launchpad to maintain a bazaar branch with all changes, and synchronize this branch on our Git.

Note: and what about Transifex which provides a client to help in the process.

Version Update Build & Check

Amend these files for version information:

  • NEWS - for a log of the changes in the release
  • configure.ac - put in the new version number
  • help/C/viking.xml - put in the new version number and date
  • win32/installer/viking-installer.nsi - put in the new version number
  • src/dialog.c - Copyright year is updated automatically
  • src/main.c - Copyright year is updated automatically
  • help/viking.xml.in - version number and date are now automatic - getting inserted on running make dist or similar.

Build the tarball

Ensure the build has every component required for the release:

./autogen.sh --enable-gtk-doc

Building the tarball is easy with auto-tools, doing minimal check is as simple as:

make distcheck

Windows Check

Before commiting files for the release you probably want to verify the Windows build is in functional state (see below).

Commit

If the distcheck was successful commit the files updated for the new version. Otherwise sort out the failure.

Tag the Release in git

Set the tag version as appropriate preferably signing it with the '-s' option using GPG:

git tag -s viking-1.6 -m 'Releasing Viking 1.6'

otherwise use the '-a' option:

git tag -a viking-1.5.1 -m 'Releasing Viking 1.5.1'

Push changes & release to SourceForge:

git push --tags ssh://<user>@git.code.sf.net/p/viking/code
  • If a new branch need to push that too, e.g. for 1.4.*:

    git push ssh://<user>@git.code.sf.net/p/viking/code viking-1.4.z

Individual 1.4.X releases can then be tagged on the viking-1.4.z branch.

Create the Manual

At the moment the PDF manual is not automatically generated, so these manual steps are required:

cd help/C
dblatex viking.xml

Only for generating the PDF manual does the dblatex tool and it's dependencies (over 450Mb!) need to be installed on your system.

Do Windows Build

 cd win32
 ./configure_and_make-wine.sh
 ./installer-wine.sh

Create the release on SourceForge site

Digitally sign the main binary files (Source code bz2 file and the Windows installer file - not worried about the PDF help file) to generate each appropriate filename.ext.sig, e.g. :

gpg --detach-sig viking-1.6.tar.bz2

The tar ball, PDF, Windows Installer and signatures must be uploaded to SourceForge - simply use the Files -> Add Files/Folders as appropriate.

Then click on the (i) for the tar file and set it as the default download file for the appropriate platforms, so that it will be linked on the main page.

Update the VERSION file on the website with new version number.

Announce the release

There are different media where to announce the new release:

Packaging

Debian

Take a look at Debian Package Tracking System for Viking, which includes a lot of useful informations and links regarding the status of the viking package in Debian, including a link to Build logs on the different Debian architectures.

The packaging files are hosted by Debian on a dedicated Viking's Git repo.

Ubuntu

Take a look at “viking” package in Ubuntu.

Gentoo

https://packages.gentoo.org/package/sci-geosciences/viking

Internationalization and Localization

Check a definition on Wikipedia.

Internationalization

Follow gettext manual.

Main job is to identify translatable strings. Next, we have to decide how to "tag" it:

  • "_(xxx)" if the context allows code execution and dynamic string
  • "N_(xxx)" if we simply want to tag the string but not translate it here (translation will be done later in the program).

Localization

You want to translate Viking into your language?

First thing to do is to generate an up-to-date template PO file. Go to ./po and type:

make viking.pot

Next, use this file in your PO editor (for example, poEdit which can propose some translation).


Related

Main Wiki: Development
Main Wiki: Main_Page