As the subject says: I want to do a point release of the stable-5.3 branch, to fix blatant crashes and some other bugs that have already been fixed on master. What I've cherry-picked so far:
git://git.openclonk.org/isilkor/openclonk.git stable-5.3
What other fixes do you think should be part of a bugfix release? Please remember that this is the stable branch so if you want to add feature patches you better have a good reason.
git://git.openclonk.org/isilkor/openclonk.git stable-5.3
What other fixes do you think should be part of a bugfix release? Please remember that this is the stable branch so if you want to add feature patches you better have a good reason.
![[de]](/mwf/flags/de.png "Germany")
patch… I found more typos while playing the tutorials, but I couldn't find them again afterwards :( I should make screenshots whenever I notice sth
I've rewrote parts of the script parser, fixing a somewhat "popular" assertion failure in the process. This has been pretty stable so far, but its too large to verify by inspection that a cherry-pick will produce something that works. So if we want http://bugs.openclonk.org/view.php?id=883 and duplicates gone, we could disable assertions in release builds, or pick basically every patch that touches src/script.Similarily, the various patches to src/platform finally brought the fullscreen window code on X11 to a state I'm actually somewhat happy with, but the partial rewrite when dropping xf86vidmode usage required some follow-up fixes later.
Actually, I can't find anything scary on a cursory glance at the engine commits. Maybe we should just release from the master branch?
The master branch receives a bit of testing because we often played our Sunday games with the dev snapshots.All unfinished scenarios are still in Experimental.ocf I think.
> Maybe we should just release from the master branch?
43a28362 should alone be resaon enough not to do it.
I think that we don't need to fix every possible bug in the 5.3 series. If a fix required significant rewriting of parts of the code it shouldn't go in a stable release.
Well, but the graphics still work, don't they? I haven't heard any complaints of people who could run the release but not the dev snapshot.
Btw, from my few test games for the menu stuff, I had the impression that everything was a lot faster. I never had 38 FPS when reasonably zoomed in and 30 FPS when zoomed out before :oCould also be a placebo effect, of course. Sven, you have tested more with a non-release engine. Have you noticed anything?
We could revert that commit in the release branch.The thing is, the dev branch is getting some testing, the stable branches not so much. We have three options:
- release from master (plus some reverts)
- organize some testing for the stable branch
- release something untested
I'm just arguing that we shouldn't do the last option :-)
Yes. Please release from the stable branch and only include critical bugfixes (tested!) and uncritical bugfixes/changes. There is no reason to include most changeset we have in a stable release.
Sorry, I seemed to have missed your reply:The fix to #883 is should definitely be included in a bugfix release. If it is critical in the sense of that it can break other stuff and thus needs testing must be decided by you.
What is the timescale for this? I suppose I have to make the release scripts figure out themselves whether the binary name is openclonk.exe or clonk.exe before pushing the button will work.
I don't have a timescale set, especially since there's no consensus yet if we actually want to release from a cherry-picked stable-5.3 or from master.
No... will try to get it done before the weekend. On Sunday itself I won't be available though since I'm travelling.
Well, do you want to release from stable or master? I'm not keen on picking and merging a bunch of commits just to find out that we're going to release from master anyway.
See Clonk-Karl. As this is intended as a bugfix (stable) release, it should be done from the stable branch.
If there's enough new stuff to warrant a 5.4 release, we can do that instead. Is there?
I think we can do that if some if the new scenarios move to non-experimental folders, otherwise there is not so much new stuff from a gameplay point of view.
Some of the scenarios (at least the lava-based ones and Gold-Seek) I'd say are ready to be non-experimental.But I'd like to hold them back and collect stuff in experimental before. Then I'd maybe order them all in a chain of missions that are connected with a very simple storyline for a release.
![[gb]](/mwf/flags/gb.png "United Kingdom")
That's another thing I meant to mention; I'm not sure on "Gold-Seek" as a name. It sounds odd.
Indeed, and it conflicts, as in being too similar to, with Gold Rush.
[x] The Clonk who went up a hill but came down a mountain
![[at]](/mwf/flags/at.png "Austria")
[X] Goldlova
Well, apart from the recent bustling activity and the work on new game content lead by Sven2, I still think it makes very much sense to make an intermediate stable release before we prepare a new feature release with only bugfixes etc.Experience tells us that getting the new content bugfree and cleaned up for a release will always take more time than expected, so the new scenario content, Zappers menu, etc. won't be ready so quick that an intermediate stable release will be superfluous. But then again, perhaps quicker than I think, that is why we should get the stable out there already.
One reason I am so in favour of an additional stable is because our game is in the Debian package repository. Debian users (on stable) are always stuck with a "stable" version, let that version be really a stable version and not just an "old" version.
So, I am calling for a stable release on this weekend, Sunday the 3rd March
We have time until Friday/Saturday to create even more bugfixes for stable, Sunday it is just testing in #openclonk and the release.
I suggest we do it after test-playing on Sunday then to make sure no new bugs have been introduced. Otherwise, the stable branch would be completely untested.
> One reason I am so in favour of an additional stable is because our game is in the Debian package repository. Debian users (on stable) are always stuck with a "stable" version, let that version be really a stable version and not just an "old" version.
OpenClonk's not in the next Debian release. We missed the freeze window by a few months, I think. Still, another stable release is always good. Except when it is less stable than the current master branch...
#883 isn't fixed in the stable branch. I'm sorry I put us in this situation - I really should have done the store-bytecode-in-functions change before messing with function pointers instead of assuming I could make old the bytecode-in-scripthost design continue to work.So we have a bunch of options:
a) Don't fix #883 in 5.3.3
b) Remove the assertion and hope that that makes it work. It probably will, but I've been mistaken about that code before...
c) Release from the master branch, maybe with 43a28362 reverted (that commit did have some problems, but ck fixed the ones I encountered, so its not totally clear)
d) Pick most or even all script-related commits
e) Try to reason out the minimal set of script-related commits needed to fix #883 without new bugs (by this point, I've forgotten whether I needed to fix bugs introduced by af62ab7931)
I don't think d) and e) are particularly productive, but if someone wants to do the work, I'm not stopping them. Perhaps they'll even find something while reviewing the commits :-) I'm ambivalent about a), b) and c).
>b) Remove the assertion and hope that that makes it work. It probably will, but I've been mistaken about that code before...
Is there a way to test that it really works?
No mysterious crashes or misbehaviours when playing multiple rounds without restarting the engine would indicate that it worked.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
