Since the 6.0 release already some important bugs have been fixed and we should consider a 6.1 bugfix release in the next month or so. Open issues can be found in the roadmap and would especially ask the devs working on the lights system to try to tackle to low-hanging fruits in there.
We decided to do a release of the stable-6.1 branch and therefore it is a good idea to keep track of the commits in master which did not go into that branch.
If your commit is a bugfix which is sure to not break anything else, please directly cherry-pick it into stable-6.1.
List of commits in master but not in stable-6.1 (produced with git cherry stable-6.1 master -v)
+ f0579f7f93959c5962039dba78953d251f647c49 gl: Use fewer uniform components to upload bones (#1285) (squashed into 61ffb0f)
+ 59cad71797bf5076d420b9be5ff996ebcdcab60a Add copyright header and descriptive comment to default object VS (squashed into 61ffb0f)
+ d6f219a3dfd7c0fd9dee20c3125fdb6f3b590800 Use 3x4 bones on low MAX_VTX_UNIFORM_COMPS (#1285) (squashed into 61ffb0f)
+ 5562b09dc493cd07bc96df8716f8773ff7cfda66 Remove a lot of disabled legacy code, round 2 (not stable)
+ cd266d23523c32d4ec8760cd38ada9b368715e3f gl: Attach debug labels to objects (not stable)
+ be1a1489153b59c2e6f8a91a046f534511fbbb2c Aul: Remove C4AulAccess enum (not stable)
+ b2f742f997c827011cdb4df30e8403d2408cb8e8 gl: Check glew for GL_KHR_debug support (not stable)
+ c58e474f76a5dda2a1c68fd105f86c8890a41b5a win32/GL: Reuse the same rendering context for everything (not stable)
+ d951827f174ccf7214736856ef20fd860660ddca Particles: Don't force vertex buffer workaround on Win32 (not stable)
+ 874a9f263281a312f0cb00f2a45bfca81c8c54ae Pathfinder: Use callback functors instead of raw function ptrs (not stable)
+ 2338bead11d4aa2c5e7f2b2b831ef76ff45e6ffc Move C4PathFinderRay from header into implementation (not stable)
+ 5f461614336c526d0f14a494b04e927ac9e14aa1 Remove unused clone of C4PathFinder (not stable)
+ 7381ef7df0f0a7d7b572147d9e2015a8b10c6977 gl: Enable shader logging if DebugOpenGL is active (not stable)
+ cd807841409b02d400df97704e774bec50d9852a Save ambient brightness value in savegames (stable?)
+ d03271ec6eb06b480406bc698d3ed00c91a5e1a4 SetCommand Jump uses flight control and fix ObjectComJump() (stable?)
+ 035e1fc8080d59243668cf148cd0f87816649b0e Docs: Correct DoEnergy() and AddCommand() examples (#1305) (just a docs change)
The stricken out entries are already in the stable branch because of commit squashing or should not be cherry-picked into stable.
We decided to do a release of the stable-6.1 branch and therefore it is a good idea to keep track of the commits in master which did not go into that branch.
If your commit is a bugfix which is sure to not break anything else, please directly cherry-pick it into stable-6.1.
List of commits in master but not in stable-6.1 (produced with git cherry stable-6.1 master -v)
+ cd807841409b02d400df97704e774bec50d9852a Save ambient brightness value in savegames (stable?)
+ d03271ec6eb06b480406bc698d3ed00c91a5e1a4 SetCommand Jump uses flight control and fix ObjectComJump() (stable?)
The stricken out entries are already in the stable branch because of commit squashing or should not be cherry-picked into stable.
> + f0579f7f93959c5962039dba78953d251f647c49 gl: Use fewer uniform components to upload bones (#1285)
> + 59cad71797bf5076d420b9be5ff996ebcdcab60a Add copyright header and descriptive comment to default object VS
> + d6f219a3dfd7c0fd9dee20c3125fdb6f3b590800 Use 3x4 bones on low MAX_VTX_UNIFORM_COMPS (#1285)
These are actually in stable-6.1, but I've squashed them into 61ffb0f.
> + 5562b09dc493cd07bc96df8716f8773ff7cfda66 Remove a lot of disabled legacy code, round 2
> + cd266d23523c32d4ec8760cd38ada9b368715e3f gl: Attach debug labels to objects
> + be1a1489153b59c2e6f8a91a046f534511fbbb2c Aul: Remove C4AulAccess enum
> + b2f742f997c827011cdb4df30e8403d2408cb8e8 gl: Check glew for GL_KHR_debug support
> + c58e474f76a5dda2a1c68fd105f86c8890a41b5a win32/GL: Reuse the same rendering context for everything
> + d951827f174ccf7214736856ef20fd860660ddca Particles: Don't force vertex buffer workaround on Win32
These aren't suitable for inclusion into a bugfix release.
This patch (fd6914f9cba6d7138b57c7fa6faa7437d9cbb639) fixed some SDL linking problem some people had with 6.0, which is why I had to include it for the AUR. I don't know enough about linking, which is why I'm also not sure why the patch works. Could somebody clarify and/or include it for 6.1?
It's in stable-6.1 as 4674c82cdff0b9c5177edd3906a4453313f2f52d.
Should we increase the version on master and then cherry-pick into stable-6.1? Or rather directly commit that change to stable-6.1?
I have made the list with cherry-picks up to date, currently there are two commits which are still unclear, the rest has been picked.
In principle we can go ahead with a 6.1 release this weekend.
In principle we can go ahead with a 6.1 release this weekend.
Okay, I've arbitrarily decided that stable-6.1 is frozen now and only critical fixes may be committed. This is mostly because 6.0 has been quite a while and there have been important fixes made to it that really should be released RSN. So if nobody finds anything that absolutely needs to be fixed before 6.1, I'll push button on Sunday.
But is not something which will be fixed during the next few weeks probably, and we can always release a 6.2 from the same branch (which leads me to the suggestion to call the stable branches stable-7 and so on, so that we can release 7.1, 7.2, 7.3 from that branch).
Umn I think it's trivial. There's probably just some conversion missing/going wrong from when the key config was changed from key codes to scan codes.
Well, obviously if you have time for that, but at some point we need to push the 6.1 and make way for the controls branch.
That's certainly possible, but as far as I know nobody has even investigated yet and/or stated they'd handle it, and while I'm aware that the bug tracker entry isn't that old yet, we have a bunch of fixes in 6.1 that make people able to play in the first place after it's been broken in 6.0. So I'm sorry for people not using the default control scheme, and if somebody writes a fix before Sunday, I'm happy to fast-track that into the next release, but at some point we have to release an update. I mean, this thread is almost two months old, 6.0 is over two months old, and yet I can count the number of people who actively contributed to a 6.1 release actually happening on half a hand.
Good!
We only need to push a version increase, which I will do tonight and I will create some snapshot using the release interface so that we can test the basics.
Ah I see you did many version related changes, what has changed now? We can mark a release with alpha and rc?
What do you think about the Version entries in Scenario.txt and DefCore.txt? It is always a hassle to update those as well.
We only need to push a version increase, which I will do tonight and I will create some snapshot using the release interface so that we can test the basics.
Ah I see you did many version related changes, what has changed now? We can mark a release with alpha and rc?
What do you think about the Version entries in Scenario.txt and DefCore.txt? It is always a hassle to update those as well.
>What do you think about the Version entries in Scenario.txt and DefCore.txt? It is always a hassle to update those as well.
They should probably eventually be removed in favour of a Version.txt in the top level of an object folder...
Like the System.ocg folder? For scenarios and scenario folders that would conflict with the versioning used by the authors.
The idea of the version is to make sure that objects have to be used with the right engine version. But usually a whole package is designed for a certain version and it's unlikely that two objects from one pack require two different versions.So I am just saying that if we want to keep the version stuff, we should probably just use Objects.ocd/Version.txt or something similar and let that propagate to all subfolders.
Having the engine functionality to require a version can be useful to ensure that something needs to be run on the latest snapshot and not the release version. But the entries could be removed from our regular objects and scenarios and only used by authors when they're really needed I think.Version.txt in the top folders may be good for people who keep copies of old/modified stuff to see where it came from. But it's probably not that important.
That sounds like a good compromise, because our own content is of course always supposed to be run with the engine shipped with it.
By Anonymous ![[de]](/mwf/flags/de.png "Germany")
Date 2015-05-22 14:31
A version.txt with the current version could also be kept out of the repos and be inserted by the release scripts prior to packing.
Then you have a problem when a player plays with the release version together with a developer, who is using the repository (at the release version revision)
Why would you want to do that? You can also play using your developer engine from the release directory.Edit: We never manged to play via internet directly from the repository anyway. Checksums never matched.
> We can mark a release with alpha and rc?
Yes. This is only a visual marker though, for all (internal and external) purposes the 6.1-rc1 engine uses "6.1" as its version number.
> What do you think about the Version entries in Scenario.txt and DefCore.txt?
I don't have a strong opinion on those. With the changes though you can now change the version entry to whatever the next engine version will be if you use some functionality that's not provided by earlier engines (so you can require version 7.0 and 7.0-anything will be sufficient, instead of requiring 5.99.3 for the in-development versions of 6.0 or whatever). I don't think we have to bulk update every entry.
I can't seem to build a release candidate using the release button, it seems to be broken. ck?
![[us]](/mwf/flags/us.png "United States")
I restarted the process, and it works for now. Not sure what was stuck.
./openclonk: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by ./openclonk)
./openclonk: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./openclonk)
for ubuntu 14.04 x64
same for snapshots and 32-bit:
./openclonk: error while loading shared libraries: libvorbisfile.so.3: cannot open shared object file: No such file or directory
./openclonk: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./openclonk)
for ubuntu 14.04 x64
same for snapshots and 32-bit:
./openclonk: error while loading shared libraries: libvorbisfile.so.3: cannot open shared object file: No such file or directory
The autobuilds are produced on Debian Stable. If they don't work on a different Linux distribution, I'm very sorry, but that's for their maintainers to figure out. (They just have to rebuild with whatever gcc is available on that release.)
The main reason for the autobuilds existing is to check that building OpenClonk works on all platforms we support. That this produces binaries at the same time is a nice side-effect - but not mission critical, especially on Linux, where you can have a full devel environment set up with a couple of keystrokes. And while we can easily distribute a full set of required libraries on Windows (because on there we only have to drop them in the same folder as the binary itself), doing so on Linux is considerably more annoying - either we'd have to change the RPATH to also look in the current directory, which is not reasonable for installed binaries, or we'd have to ship a wrapper for uninstalled binaries that sets the library path at runtime. Alternatively we could produce statically linked binaries, which I'm pretty sure is all but impossible to do with CMake without pre-populating the CMake cache with all required libraries - something I won't do because that would hide problems with library lookup from within CMakeLists.txt.
The main reason for the autobuilds existing is to check that building OpenClonk works on all platforms we support. That this produces binaries at the same time is a nice side-effect - but not mission critical, especially on Linux, where you can have a full devel environment set up with a couple of keystrokes. And while we can easily distribute a full set of required libraries on Windows (because on there we only have to drop them in the same folder as the binary itself), doing so on Linux is considerably more annoying - either we'd have to change the RPATH to also look in the current directory, which is not reasonable for installed binaries, or we'd have to ship a wrapper for uninstalled binaries that sets the library path at runtime. Alternatively we could produce statically linked binaries, which I'm pretty sure is all but impossible to do with CMake without pre-populating the CMake cache with all required libraries - something I won't do because that would hide problems with library lookup from within CMakeLists.txt.
Interesting, I did not know that. This is a very valuable information. Do you think it makes sense if you mention this on the autobuild pages that they are built for Debian?
Button will be pressed tomorrow at 19:00. Let's hope things work!
Were there any test games?I've just moved to Providence, RI now. Maybe in a few weeks I'll have time again.
ooh :o
Cool, good luck over there! This year I am not visiting that area (but CA), maybe next year, ck is also in the neighbourhood, right?
I did not test network games, but well, this took too long.
I did not test network games, but well, this took too long.
I'm oscillating between Boston and NYC, but will move to the SF area later this year. When are you visiting CA?
Last week of August, in Lake Tahoe, but planning to visit SF in my private time.
Cool, that's more or less around the corner. We should meet up some time :)
Done, the one responsible for the Mac build and the source package please take over that task.
What's with the Desura Release? I believe we have been neglecting that
I have contacted the package maintainer which actually have an email address on their package site (only 3), is there an easy way to contact them?
B_E you are probably here, so if you read this you know what to do :)
Newton: the Fedora still misses a link, maybe you can add this one http://rpm.pbone.net/index.php3/stat/4/idpl/29192683/dir/fedora_21/com/openclonk-data-6.0-1.fc21.noarch.rpm.html
B_E you are probably here, so if you read this you know what to do :)
Newton: the Fedora still misses a link, maybe you can add this one http://rpm.pbone.net/index.php3/stat/4/idpl/29192683/dir/fedora_21/com/openclonk-data-6.0-1.fc21.noarch.rpm.html
Very good news! The Mac snapshots are working and are now also generated when the release button is pressed. A big thanks to ck for this!
Mortimer, could you test both the download for the release and the snapshot and tell me whether they work?
This means that a 6.2 release would be much more convenient to do, so in case someone has some fixes which need to be released we can set up a branch for a 6.2 release or use the 6.1 stable branch.
I think in the future we should name our stable branches stable-7, stable-8, etc. from which we can release 7.1, 7.2, etc.
Mortimer, could you test both the download for the release and the snapshot and tell me whether they work?
This means that a 6.2 release would be much more convenient to do, so in case someone has some fixes which need to be released we can set up a branch for a 6.2 release or use the 6.1 stable branch.
I think in the future we should name our stable branches stable-7, stable-8, etc. from which we can release 7.1, 7.2, etc.
> Very good news! The Mac snapshots are working and are now also generated when the release button is pressed. A big thanks to ck for this!
:-O
The release button page needs to be updated then.
> Mortimer, could you test both the download for the release and the snapshot and tell me whether they work?
By the way, I'm just taking the .zip files produced by the autobuilder 1:1 for the mac snapshots and releases.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
