Menu ▾ ▴

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: in Launchpad there is a bazaar branch to attempt to synchronize, however this is still method is currently broken due to https://bugs.launchpad.net/bzr-git/+bug/1313861

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

Instead currently performing semi manual imports / exports - which also removes all the 'noise' generated by default in i18n files.

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/index.docbook - put in the new version number and date
  • windows/installer/viking-installer.nsi - put in the new version number
  • org.viking.Viking.appdata.xml - new release version (newest at the top of the release list)
  • org.viking.Viking.yml - point to the new branch (even not created yet! as this is done after )
  • 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.

Note about creating NEWS

Manually scan the git changelog (e.g. with gitg or similar) and create a list of the important new features or changes that would be interest to the typical user. i.e. the typical user doesn't care about all the individual commits.

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 -j 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</user>

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 this manual step is required: 

dblatex help/C/index.docbook -o help/C/viking.pdf

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

Update HTML Help

Update the HMML Help on https://viking-gps.github.io

See help/C/ReadMe.txt for current instructions - i.e. use of xmlto to convert from DocBook into HTML.

Do Windows Build

more windows/README.txt
# [Do build in OpenSUSE VM...]

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.

[Optional] Maintain secondary repositories (i.e. github)

Push new tag to github and add release notes there too.
git push --tags viking-gps

Flatpak build

Create own viking.flatpak file - e.g. for a complete clean and reset:

rm -rf .flatpak-builder/ && rm -rf flatpak/ && rm -rf flatpakrepo/
flatpak-builder --repo=flatpakrepo flatpak/ org.viking.Viking.yml --force-clean
flatpak build-bundle flatpakrepo/ viking.flatpak org.viking.Viking

Also see the file FLATPAK.md for more notes about this

Update Flathub...

Announce the release

Find authors for this version e.g.

cd maintainers
./extract-authors.sh viking-1.7..viking-1.8

Edit this wiki as appropriate

  • Main page
  • New version notes
  • Update Help with latest Manual

Announce

There are different media where to announce the new release:

Update Bugs & Features tickets

Formally close any tickets that have been addressed by this 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