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:
for x in `ls po/*.po`; do if [ $(git diff $x | wc -l) -gt 15 ]; then echo $x; fi ; done
git show | sh maintainer/git-diff2po_ChangeLog.sh > po/tmp ; cat po/ChangeLog >> po/tmp ; mv po/tmp po/ChangeLog
cd po ; make viking.pot
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.
Amend these files for version information:
Ensure the build has every component required for the release:
Building the tarball is easy with auto-tools, doing minimal check is as simple as:
Before commiting files for the release you probably want to verify the Windows build is in functional state (see below).
If the distcheck was successful commit the files updated for the new version. Otherwise sort out the failure.
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.
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.
cd win32 ./configure_and_make-wine.sh ./installer-wine.sh
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.
There are different media where to announce the new release:
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.
Take a look at “viking” package in Ubuntu.
Check a definition on Wikipedia.
Follow gettext manual.
Main job is to identify translatable strings. Next, we have to decide how to "tag" it:
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:
Next, use this file in your PO editor (for example, poEdit which can propose some translation).