Is there some scheme for when and how we release an update? Because there are quite a lot changes which improve gameplay already. If bug 222 is fixed I think it would be a good idea to throw in an update, what do you guys think?
![[ca]](/mwf/flags/ca.png "Canada")
I think the most important bugs to fix for an update are ![[de]](/mwf/flags/de.png "Germany")
I am more concerned with the general structure of who does what, do we have one person that will "cherry pick" commits and puts them into release and then increases version.txt to create an update?
Or should the one that commits decide what belongs in release and what not, and "cherry pick" himself. And then someone randomly decides we have enough new commits in release, let's update.
P.S. ck just told me the build scripts are not adapted to the release branch yet.
Or should the one that commits decide what belongs in release and what not, and "cherry pick" himself. And then someone randomly decides we have enough new commits in release, let's update.
P.S. ck just told me the build scripts are not adapted to the release branch yet.
cause we are the only ones who can change version.txt anyways.
We are also the only ones who can change anything else directly but other development discussion does not happen in private.
Hmm, I want to keep this internal at least until we reached a common agreement on how to proceed. I fear that this topic would drift off into some large scale discussion in a public board. After all, this really concerns just us. I don't want to bloat this topic like it happened for the search for the name/subheading which also only got resolved in the internal forum btw.I think it is better to limit the number of opinions to those of the developers here because we will do the actual maintenance work for creating updates and patches.
> I fear that this topic would drift off into some large scale discussion in a public board (especially with people like Asmageddon around).
I don't. Actually I am quite positively surprised of how few discussions really drift off in our forums. And if it does then we can still lock or move branches. I'd volunteer to do that if that makes you change your mind.
> I think it is better to limit the number of opinions to those of the developers here because we will do the actual maintenance work for creating updates and patches.
With the same argument you could also move most development discussions into the private board.
Another option would be to make it publicily readable but let only developers reply to the topic. But I'd still prefer the all-open variant.
I think be have two decide betweena) doing only bugfix releases with the effect that the players (the actual players who have no clue how revisions work) do not have the newest version they could have.
b) doing releases of everything that "works" so that the players always have the best experience when playing OC. Things like the settlement stuff will of course not go in there until they are finished from our point of view (but new Melee scenarios for example, can!)
first
Some thoughts on the two approaches. The "almost everything goes in"-approach has the advantage that it's relatively easy to maintain. We just release from the main branch. Settlement scenarios and objects go into test folders; fundamental engine changes should be developed in separate branches anyway. There is no need to cherry-pick commits and deal with merge problems. Also, new content gets lots of testers and feedback.An advantage of the "bug fix only"-approach is that we actually get new content for the next release that is not yet well known. I remember when we jumped e.g. from CE to CR, many people complained because effectively, the "jump" from CE to CR was very small for someone who kept up-to-date with CE releases. Although there were many improvements between the first release of CE and the first release of CR.
This is really an important, fundamental decision and I think we should have a vote on it.
>An advantage of the "bug fix only"-approach is that we actually get new content for the next release that is not yet well known
Yes, we would really only have "new" content when we finish major stuff (like settlement)
> fundamental engine changes should be developed in separate branches anyway.
They do need to be merged and tested in context eventually, though, and less fundamental changes can break the game just as easily.
So we do need a certain amount of time between releases to get new features into shape. This doesn't have to be between every release: We could do a release candidate followed by a 1.0 followed by a bugfix release and then merge new features and stabilize. It's too late for that for BttR, though.
So the question is whether we maintain a separate stable branch. If yes, does it get the "default" label in hg? Do we merge the stable branch into the unstable one(s), or do we pick patches from the unstable branch to the stable one? All four approaches can work, I think. The differences are in how much of the responsibility is shared between everyone who can push. In the "unstable is default, patches are picked", only the ones responsible for the stable branch need to care. This is how the repository is set up at the moment. With "stable is default and merged into unstable", we all would have to decide for every patch whether to push it to stable or unstable. "unstable is default, stable is merged into unstable" is something in between, and "stable is default, patches are picked/pushed separately to both" sounds a bit cumbersome.
So we first need to get someone or a group of developers who want to maintain a separate stable branch. If this is all or nearly all of us (I for example would be willing to help, but probably not do the work alone), we can decide whether we want to switch the model from "unstable default, patches are picked" to one of the others.
For now, I am for the first solution because I think that nobody will be found who is willing to maintain a separate stable version and pick only the bugfixes regularly (I won't). I am aware that in this case we can not really name our engine "stable": In the continuing redesign and refactoring of the code that happens during development, there will always pop up new issues. I am not so optimistic to deny that this happens regularly even with thorough testing beforehand.
> I think that nobody will be found who is willing to maintain a separate stable version and pick only the bugfixes regularly (I won't).
Picking the patches itself is a small part of the task. One can even get a reasonable approximation by just picking all patches that have a bug number in the summary and still apply. I can do that part for the engine and for game data patches with good patch descriptions. But the result does have to be tested again to shake out the bugs that result from the patches being taken out of context. If we can get that and the autobuild branch support done (though I'd prefer using a separate repos just to avoid the obnoxious nature of hg "branches"), we should have a small stable release update ready.
> Picking the patches itself is a small part of the task
> But the result does have to be tested again to shake out the bugs that result from the patches being taken out of context.
And that's why I think this is too much maintenance work. As you point out, the maintainer who does the patch-picking can not guarantee that the stable branch now works as much as you cannot guarantee that f.e. the physical patches will work flawlessly. But still it will be expected somehow that he takes responsibility for that. So the story is not over, here: What has to be done after one round of cherry picking is again some extensive testing by several people who would, well, otherwise work and test on the main branch with the time they have for clonk.
My concern is that I believe we don't have the manpower and will to maintain those two branches, regularly switch between them and test those. Or well, that if we do it, the whole release & bugfix cycle will turn into a really lengthy and cumbersome process. Something, that I wouldn't like to see happening.
So, I'd vote for keeping one branch and when somebody wants to fire out a new update, he will note the team about his plan in advance so everyone has time to test his changes for stability or adheres from pushing some crucial changes just before that update.
I'd also say we should generally focus on bugfixing at least in the engine at the moment. I don't really like all the refactoring that is going on at the moment. I have a feeling it generally leaves the engine in a less stable state.After I played around a bit yesterday, I wouldn't actually recommend an update to the release right now. A lot of the viewport/windowing stuff was broken. On the other hand, an update would be really crucial, because some engine fixes might have resolved the issue of constant crashes after a round/when you start the second game.
> I have a feeling it generally leaves the engine in a less stable state.
I don't think so. The console split patch that broke viewport/windowing stuff was an isolated mistake, it simply wasn't as ready as it superficially looked. I probably should have made Mortimer split that patch up in nice reviewable chunks, but he already had done a lot of work to make his patches better. Fortunately, I think further mistakes in that area can be effectively limited to the Cocoa port.
My impression too is that the engine refactor works are especially bug/error/crash prone. Because of the fatality of this as opposed to a c4script error or bug, I'd suggest that these would be developed and tested in a branch ... if they weren't already (f.e. the physicals again).
> Or well, that if we do it, the whole release & bugfix cycle will turn into a really lengthy and cumbersome process.
It doesn't need to. The amount of work is proportional to the amount of patches we pick. If we limit ourselves to the most important simple bugfixes, we only need to test for embarrassingly obvious defects. It'd be nice if we didn't introduce any new small bugs, but for example trading a script error message for a crashbug seems acceptable to me.
> It doesn't need to. The amount of work is proportional to the amount of patches we pick.
So testing a few of them separately also improves the main branch. Some of the new bugs in the stable branch will result from taking patches out of the main branch context, but others will also be present in the main branch. So the work lost to the main branch is the process overhead plus some risk for each patch in the stable branch, while the gain is hopefully in happier players. I think it's worth it, as long as we try to minimize the risk.I'll go ahead, select a few patches and push them to a separate repository on bitbucket. Then it'll be ck's decision whether he wants to build stable updates. If yes, you'll get to decide whether to publish them on openclonk.org. I don't think we'll get consensus by discussion on this because nobody has any experience with openclonk stable updates, so we'll have to fall back on everyone deciding whether they want to do the work. At least for the first time, afterwards we'll all have better arguments to convince each other :-)
OK. Sounds reasonable.>I'll go ahead, select a few patches and push them to a separate repository on bitbucket. Then it'll be ck's decision whether he wants to build stable updates.
Why on bitbucket, though? If the stable branch were the default branch, ck wouldn't have to change his scripts.
>Why on bitbucket, though? If the stable branch were the default branch, ck wouldn't have to change his scripts.
Nothing against having it in the main repository - but I would prefer an own "stable" branch for that
I also think there should be a separate stable branch in the main repository. Changing the release scripts to also release from that branch should be easily doable.
> I also think there should be a separate stable branch in the main repository.
There is: it's called "stable-5.1" ;-)
> Why on bitbucket, though? If the stable branch were the default branch, ck wouldn't have to change his scripts.
Because I'm going to pick the patches with gitk, and I don't want to waste time sticking hg branch labels on the commits. If you all really want to have the stable branch in the same repository, I'll figure out how to do that efficiently. But maybe ck can have a look and check whether using a second repository on hg.openclonk.org wouldn't be even easier than using hg branches.
![[pl]](/mwf/flags/pl.png "Poland")
What about daily bugfixes, weekly updates and monthly 100% stable 'releases' ?
EDIT: The hell? When I pressed reply, I've only seen like ~6 posts.... or am I blind?
EDIT: The hell? When I pressed reply, I've only seen like ~6 posts.... or am I blind?
> What about daily bugfixes, weekly updates
Well, this is what the nightly builds and snapshots are for.
> monthly 100% stable 'releases' ?
I don't think it should be a matter of time but rather when we feel like a release is in place.
Okay, I pushed a potential stable branch to http://bitbucket.org/guenther/openclonk-stable. I had already reviewed all the engine changes when they appeared on the master branch, so I had no problem picking out the bugfixes. For the game data changes I mostly relied on the commit messages. Unfortunately, a lot of them were less than clear, so I probably missed some important ones.
Using hg rebase onto the stable branch in the openclonk repository was enough to mark the commits with hg "branch" tags. I'm not sure that will work for further updates on top of this branch, but I could push this branch to hg.openclonk.org.
May I suggest to also include http://hg.openclonk.org/openclonk/rev/9b1c8e9ac29c? This might or might not be a fix for a crash after a scenario has finished. It should not do any harm otherwise.
You didn't include a lot of changes. What for example about all the changes to the scenarios and object behaviour?f.e. to just quote a few of the older ones:
http://hg.openclonk.org/openclonk/rev/e7fae729e8d3
http://hg.openclonk.org/openclonk/rev/b58967e330ea
http://hg.openclonk.org/openclonk/rev/39b3bfd1b6e1
http://hg.openclonk.org/openclonk/rev/136ac9fad142
http://hg.openclonk.org/openclonk/rev/00e8feef5d7b
http://hg.openclonk.org/openclonk/rev/ba6a857f6fbc
http://hg.openclonk.org/openclonk/rev/ec891b711f5e
... (and about 20-30 more)
And also, please include this:
http://hg.openclonk.org/openclonk/rev/657b6803d787
How will you keep track of what you added and what you didn't add? I remain deeply uneasy about this, especially after I saw the very incomplete "cherry picking" just now.
we could possibly include all changesets that include the BTTR folder. i dont recall changes in there which are related to important engine changes we possibly wont push (if there are any)
> You didn't include a lot of changes. What for example about all the changes to the scenarios and object behaviour?
They weren't obviously enough pure bugfixes.
For all I know, LifeGems fading out could turn out to be better.
That sounds like significant changes that might or might not make a better scenario. I'd have to playtest both versions to find out, I have no time for that. The other changes you quote are probably similar. I'm actually surprised that you're arguing for a less conservative stable update - weren't you just arguing against a timeconsuming stable release process? The only way to keep the time spent on this short is to keep the changes small, or to not review them. We could do the latter for game data and the former for engine changes, but that runs into the problem of game data changes depending on new engine features. We don't have many of those yet, I think, but that will change soon.
Of course, we could also change to the model of a stable branch where everyone pushes changes they think appropriate. I didn't get the feeling that there was consensus that we should do this. It would make the work of picking patches from the unstable branch harder, so unless everybody participates, we'd probably miss important patches.
Or we could split the work and have somebody familiar with the game data pick game data patches. Do we have someone willing to do this?
> How will you keep track of what you added and what you didn't add?
I keep the thing in a revision control system ;-) For the next update, I'd simply look at the changes that were added to the unstable branch since the last stable release, and any that I noticed were missing. Like the two you and ck pointed out.
> That sounds like significant changes that might or might not make a better scenario. I'd have to playtest both versions to find out, I have no time for that. The other changes you quote are probably similar. I'm actually surprised that you're arguing for a less conservative stable update - weren't you just arguing against a timeconsuming stable release process?
Hrm. Yes, and reviewing/playtesting each and every gameplay related patch before including it into an update is an incredibly timeconsuming release process. But sooner or later, those patches must be part of an update. What will you do then? Never include them because you have no time to review them or what?
I was arguing against this whole system of having to maintain two branches, cherry-picking certain patches out of the main branch because of this! If just everything in the default branch gets added to an update, not each and every patch needs to be selected for the next update manually. Bigger works that might make the game unstable should be done in branches other than [default] anyway.
> I keep the thing in a revision control system ;-) For the next update, I'd simply look at the changes that were added to the unstable branch since the last stable release, and any that I noticed were missing.
So, err, when do all the other changes I pointed out get added? Probably when somebody "familiar with the game data picks game data patches"? If the answer is yes - well, that's that kind of grinding maintenance work I try to make comprehensible to you.
Okay, let me explain the usual model of stable and unstable branches.The stable branch only gets patches that are known to not make things worse. What exactly that means is different from project to project. Some require more certainty in the knowledge than others, some do more work to produce that knowledge than others. I propose we use not a lot of work, but require a modest amount of certainty, resulting in mostly trivial bugfixes.
The unstable branch operates on entirely different rules. After a release from the unstable branch, the rules for the unstable branch are the loosest the project uses. We're mostly using "anything goes". Over time, the rules become stricter, until only release-blocking bugfixes are allowed. When no release-blocking bugs are left, the cycle begins anew. That's the point in time when "all the other changes" not in the stable branch are in a release. They got reviewed by being tested.
Releases from the unstable branch might or might not be descendants of releases from the stable branch. They are, if bugfixes are first pushed to stable, then merged into unstable, or they aren't, if bugfixes are first pushed to unstable, then picked to stable. I wrote about that earlier in this thread.
Typically, releases from the unstable branch are numbered X.0, releases from the stable branch X.Y with Y > 0.
The reason to use this model is that you need time to find and fix bugs after you merged big new features. You can try to find them earlier by publishing the features on separate branches, and that's certainly a good idea. But a lot of bugs will only be found by people who have no direct interest in that feature and won't download the branch, but who do have an interest in the next big release. We can't test every scenario for every feature, but we can test every scenario before every release from the unstable branch. Or, at least, every interesting scenario will be tested after a release by some random player who will hopefully care enough to report the bugs they find.
OK, I see. However, we will not have stable and unstable releases parallel to each other but only(?) one queue of continuous updates. So according to that usual model you talk of, it will jump to much more unstable when we finally decide that it is time to include all those gameplay enhancements - when we jump from 5.1.0.X to 5.1.Y.0.It's just very disappointing to not see those content changes in the next update, even though they are obviously not critical if they turn out to spark problems (in sense of can induce crash, spark wide-ranging odd bugs). (See Zapper.) If we implement this update-model, I am strongly for including any enhancing content-changes next to the bugfix- and minor changes in the engine for stable releases (5.1.0.X) and only use the "unstable" releases (5.1.X.0) for adding new game content (new scenarios, new objects like the catapult etc.) and engine changes.
But well, then only few things won't be included in the next update - at least for this update but this is OK because most of the changes were indeed minor improvements that came from feedback.
Without a stable branch, the next update will be months away. We might have a relatively high-quality game in the unstable branch at the moment, or we might have something full of bugs. So we're not delaying the release of the content changes, we're just releasing some other improvements earlier. We can try to release more changes earlier, of course. Which way do you prefer? Should I pick game data changes without review? Or just the ones reviewed by other people and mentioned in this thread? (Basically Hideout and those you linked to.) Or does somebody else want to do the picking?Edit: A result of "no review" is available at the same location as 5.1.1. Earlier in the branch is the result of "just the ones mentioned in this thread", at eca9e34bdb06. I have no idea whether it's any good, somebody else will have to decide which one to use. Feel free to rebase the branch to get rid of my version markers if necessary.
> Should I pick game data changes without review?
Yes, thats what I was saying. Except if it is part of a larger addition to the content like a new scenario, a new object (system) like a catapult, a menu etc.
I'll just push 5.1.2 to hg.openclonk.org then, if nobody objects.
I assume this conflicts with:
from http://blog.openclonk.org/. From which an objection might be deduced.
>The Thunder Scroll is only available in Thunderous Skies (coming with the next patch).
from http://blog.openclonk.org/. From which an objection might be deduced.
The next patch is 5.1.3 ;-) Also, a scenario that has only been three days in the repository is far too risky for a stable update.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
