It is pretty interesting to see how people release the actual tarballs of there free software. Some include there version controll systems metadata (I’ve once saw a release which was obviously done from the home-directory and therefore include a few private dot-dirs) and some also change tarballs silently. When you create packages for a distribution, such habits are pretty annoying and sometimes it is not possible to create sensible packages or build instructions from the official tarballs and therefore you have to recreate your custom tarball.
Add the tarballs version to your tarball name
Name your release tarball packagename-0.2.ext to make sure, every release has its unique location (yourhost.com/releases/packagename-0.2.ext). For example, Wordpress does that completely wrong (latest.tar.gz). Do not try to obfuscate the version syntax (0_2, 0-2 or something like this instead of plain simple 0.2). In a webserver directory listing your packages are sorted correctly, the chance of silently replacing tarballs by accident is much lower. Which brings me to the next point:Never replace tarballs without incrementing the version number
»But I just changed one …«. No. »But it’s harder, because I need to recreate the checksums«. Yes, you do. »I feel embarassed, because my last release was bad«. Oh, you should, but you can’t change. I say this again and again. There is no reason – and by no means no – why you should replace a tarball you have released. If you fix a hole, just increase the minor version.Remove temporary files
If you have a makefile, run make clean before you release or provide a whitelist of files which should be included in a tarball. Oh, and do not release binaries, I will rebuild them anyway, because I have my own toolchain, thanks. In case of web development, please add a clean config-file, I do not need to know your weak database root password. Also please remove your version controll system files.Build and execute your release once
When you think, your tarball is done (or atleast you think), unpack the tarball on another location and build/execute your software. Make sure you did not forget a file or something like that. Yes I could pull it from your version controll system, but why should I?Create a subfolder
Please make sure, that you have one node before your bunch of code. /test.c is wrong /mypackage/test.c is much better. Best is to include the version number in the subfolder too (/mypackage-0.2/test.c). Otherwise you will flood my filesystem, and you are not supposed to do.Provide checksums
How could I be sure, that your tarball is an intentional release by you? First of all, to check tarballs integrity, I would like to have checksums. No, not MD5, provide multiple checksums because the ones which are widespreaded are more or less broken (SHA256 plus MD5 is ok). Please also sign your tarball or your hashes with your GnuPG-key. And yes, your key is worthless if noone signed it. A nice thing is to provide HTTPS for package downloads but that’s pretty hard for obvious reasons.Use a consistent version scheme
If you thought out a version scheme, stick to it. It might be bad, but at least you’ve tried. When you change, please document that clearly.
Filed under Free Software, Open Source, Release
&
no comments
&
no trackbacks
Trackbacks
Trackback specific URI for this entry
Add a Comment & let me know what you think