The first update to Back to the Rocks has been released. This update includes lots of bug-fixes and improvements to the scenarios. Get it from the download page or the repository. Enjoy!
I'll look at why this doesnt show on the DL page later this day. Clonk-Karl, as you currently have FTP access to the server, you could also take a look at the log of the masterserver in the meantime.
I don't see any masterserer log on ftp.openclonk.org.
It would be good if we had a (text) changelog of the changes made for that version for a news entry. I found no option in TortoiseHG to print the commit messages of a given list of changes. Why is it 5.1.1.3 now btw? For me that reads like the "third bugfix update of the first update to the first release". I thought it was supposed to be the "first bugfix update of the first release" (5.1.0.1)
Also, a sidenote: I find it disappointing that HG does not display the two exact same changesets as connected in the graph (merged into 5.1.1 branch). Makes it hard to comprehend which changesets had been merged/applied and which not.
Also, a sidenote: I find it disappointing that HG does not display the two exact same changesets as connected in the graph (merged into 5.1.1 branch). Makes it hard to comprehend which changesets had been merged/applied and which not.
I was recently told that the fourth version number is not a version number as the other three but rather a build number. So the version should rather read 5.1.1 [3]. The release script was written with another scheme in mind, so it creates 5.1.1.3.
I'm not quite sure what to make out of this. I would prefer to remove the build number if possible, since compatibility in network games is already ensured via the engine's hg revision ID.
I'm not quite sure what to make out of this. I would prefer to remove the build number if possible, since compatibility in network games is already ensured via the engine's hg revision ID.
>So the version should rather read 5.1.1 [3]. The release script was written with another scheme in mind, so it creates 5.1.1.3.
That's up for us to define. I have nothing against removing that "build number" then. However, since the first version number "5" is also not a real version number (5=OC) that changes during the development of the game, we just have two version numbers left. One for the milestone (1=BTTR) and one for any update thereof. So there would be no possibility (anymore) to denote an update as a bugfix update.
Question is whether there is any need to do so. Or whether it wouldn't be enough to only change the fourth number. Whether it's written as 5.1.1 [3] or 5.1.1.3 is irrelevant anyway. The real question is whether anybody wants to do the work to make the engine work when the build number is reused. As long as the build number is used for network identification, we shouldn't reset it.
It's not a just bugfix release, though, it includes substantial changes to the game content. If we don't increase the third number now, we'll end up never increasing the second. I choose the three because I had published two release candidates with numbers 1 and 2.
To check whether a given patch is included, one can search for the summary in the log viewer. Displaying all the connections graphically would result in a huge amount of crossing connections. We could note the original commit id in the stable branch commit, but that would be more work with little gain.
To check whether a given patch is included, one can search for the summary in the log viewer. Displaying all the connections graphically would result in a huge amount of crossing connections. We could note the original commit id in the stable branch commit, but that would be more work with little gain.
Understood. And do you know a way to easily get a list of commit comments since last release for creating a list of changes? (for posting in CCAN, blog, forum etc.)
That's one reason why it makes sense to tag releases. You can get a list via
hg log -r release-5.1.1:release-5.1.0 -b stable-5.1
.
A deb package for this Release for 32 and 64 bit is available at:
https://launchpad.net/~openclonkdevteam/+archive/release
https://launchpad.net/~openclonkdevteam/+archive/release
If this can be automatically created like the win32,win64 and linux32 builds, this could be included on the downloads page. Is that possible? Also, what do the other (linux) devs think?
In general yes, it is possible, at least for 32 bit. Before doing so I'd suggest we add a compile-time option to the engine which disables automatic updating though, since otherwise we might get into the Debian package management's way (and probably it wouldn't work anyway if it's installed into a system global path).
sounds good... also I did two patches which include now icons:
http://homepages.fh-giessen.de/~srhl62/openclonk_rev2421.patch
http://homepages.fh-giessen.de/~srhl62/openclonk_rev2422.patch
Would be great if somebody could merge them into the trunk
http://homepages.fh-giessen.de/~srhl62/openclonk_rev2421.patch
http://homepages.fh-giessen.de/~srhl62/openclonk_rev2422.patch
Would be great if somebody could merge them into the trunk
I updated the patches... now the src/res/c4x.xpm will be used...
Just recognized that I did a mistake with the packaging... I Included the .desktop und the icons files at the wrong place... I try to fix this...
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill