Changes to the 0.9.20 branch since release
I'm posting this as a bit of a favour to the distros, since I've been asked by a couple of people already.
So, the main problem with the initial source release was that due to a bug in fpc, 32 bit builds using -O2 or higher were causing weird bugs. We'd encountered this before release in the Windows build, but due to a confusion of the cause, had thought it was due to changes in the Windows build env initially.
So:
0.9.20.1 - This merged the fix/workaround for the bug in fpc, and added some fixes for build problems encountered on OSX and some distro configs. As well as some minor things like a fix for a crasher with "shoppa map" lua + low quality land tex, and some minor optimisations.
0.9.20.2 - This rather hurridly replaced .1 due to rejecting trunk changes causing loss of a line in a file that was needed for the minor optimisations.
0.9.20.3 - This provides some more OSX changes, a small fix for a crasher for mask.png maps taller than 16384, and, more importantly, changes made by the Ubuntu porter trying to get Hedgewars to compile on ARM/Sparc.
0.9.20.4 - This drops some unneeded files from the package (saving 20MiB on the tarball), build system tweaks (including OSX) and includes more changes on the ARM/Sparc front, which was again the reason that triggered it.
0.9.20.5 - This final package appears to fix all the compilation problems on Ubuntu ARM/Sparc. It also excludes a few more files that were accidentally included, dropping another 11 megs off the package size.
The takeaway from this is that if you aren't packaging for ARM/Sparc, that you can just stop at 0.9.20.2, but there are some minor wins to trying .3 and .4 and .5.
Oh, and we should probably see if either we or the distros can test ARM/Sparc a bit before release...
I'd like to emphasise that all changes to the branch should not cause incompatible versions between players, apart from the situation where one player encounters a bug that was fixed for the other player, but since those were rare crashing bugs, it really doesn't matter that much (just means fewer players getting kicked out of the match).
- nemo's blog
- Login or register to post comments
Koda
The latest build for OSX is supporting 10.6 and corresponds to 0.9.20.4 source.
Matt
Thanks for the notice and tarball cleanups. Updated https://build.opensuse.org/request/show/213625 In regards to ARM: sorry, openSUSE does not have Pascal and Haskell for armv7l yet and I don't own such a device for testing. You could switch to tar.xz compression. Uploading new versions of hedgewars is still a pain with low bandwidth.
nemo
The main cause of Hedgewars file size is the audio and images. Low bandwidth would be best served by our splitting the src tarball into a data tarball and a src tarball. For the case of .1-.5 above, all the changes were in source files. If we had redistributed everything but the share/hedgewars/Data tree in a separate tar.bz2, the size would have been 13MiB.
The win of using .xz is relatively small compared to that, since the data is already compressed.
From a quick test over here, .xz saved 5.8MiB over .bz2 with compression of 82% for xz vs 84% for bz2. To put that 5.8MiB in perspective, if downloading the 0.9.20.5 .bz2 took you an hour, xz would have saved you 2m 16s.
By contrast, if we'd bundled share/hedgewars/Data separately and just had you redownload everything else for a source patch, even as bz2, the entire download would have taken less than 5 minutes (assuming that aforementioned sucky internet that takes you an hour to download the full tarball).
Really, we probably should just use tar.gz - is even more common than tar.bz2 (which is itself way more common than tar.xz) and is fast to both compress and decompress, while the size difference is still tiny. Unpacks about 6x faster, compression of 84%, just like bz2. Far faster to create than bz2 which is ofc even faster than xz, although really that's just a minor convenience for us. On the other hand, unlike kernel source, we are just getting downloaded a few times from a few distros, or people who click on the src link by mistake
Matt
Separating -data and -src is a good idea. This helps a lot for ioQuake3 based games which are even bigger. It is also possible to iterate RPMs faster because checking a 200 MB file for redundancy and permission errors takes a build server VM a lot longer than just testing the fast iterating source builds for serious compiler issues.
Koda
yeah, alongside our release numbers we could split the data and programs folder, maybe have separate releases too...
Rom﹗
Hello nemo i need help, I have a friend, he wants to register his nick but, he can't because ! = ilegal character, he needs examples acepteds pliss
nemo
Hey poli, have your friend come by live chat (IRC)
Rom﹗
ok, when?? thank u
nemo
Anytime? There's usually an admin around.
Or he could just try again, see if another image is more readable.
Shopper
oh!