Feature freeze
From now until the release, there will be a feature freeze aside from a few exeptions*.
What does that mean?
It means that we want to refrain from adding any new features to the release package. Features like new game content that can have errors and has to be tested/balanced before it is really done or that can make something else that worked earlier broken again. Improving, polishing and balancing existing stuff is not affected by the feature freeze.
So, please from now on put all new scenario and object game content in Test.c4f, this folder will not be included in releases so you can feel free to test around there. Engine coders which are developing features (in branches), please don't merge them into the default branch but in a new branch.
* the bugtracker issues in release blocking bugs which happen to be features
Whats left
All that has to be done before the release is currently in the bugtracker, which is a really not much anymore. A rough overview over the bigger points:
- Update system, Automatic release scripts and download links - Günther, Clonk-Carl, B_E(, Newton)
Introduce new clonk - Randrian, Ringwaul(, pluto & anybody that can render with blender)- Final testing of club, sword, shield plus finalization - Zapper and everybody else
Finalization of Tutorials, Melees & Races - Maikel, Ringwaul, Mimmo and otherscrashes andminor engine stuff - Isilkor, Günther, any engine coder
How quick these tasks can be completed depends on the free time each one can and wants to spend on clonk, but my optimistic guess is that we can manage this in one week. When you reply to this post, can you please make a statement on whether/how this guess is realistic in your case (and if it is justified that I boldly assigned task(s) to you)?
Release steps
The first release with CK's automatic release system will be a semi-public beta, meaning that it will (if all the automatic download link creation and build scripts work without error) be available on the download page but will otherwise not be announced big time. It should be free of bugs. (Like the nightlies only that it happens to be on the download page as 1.0 beta)
With this release, the so called unit-tests which were suggested by Sven2 will be done. These tests yet have to be supplied (by Sven2) but basically are a few bugtracker issues in a seperate meta-issue like...
"Start network game -> let someone join and start"
or "Start network game in Linux -> then let some Win user join and start"
(or whatever makes sense, could break from release to release while it is an important feature) which have to be tested once and can be resolved thereafter. This can be done in one afternoon if no new problems pop up.So if no new problems pop up, the next release named "beta" can be made public, meaning it can be included on the home page, announced in the clonk forum, clonk news page (poking Matthes) and blog.
If then again no problems pop up, it can be released as OpenClonk 1.0 (without "beta") and announced beyond the borders of the clonk community.
If new problems pop up, and that will happen, we make intermediate beta releases before reaching the first "stable" 1.0.
Also, this is just the rough plan, not accounting for any problems which might pop up here and there.
They will more or less be everything the player sees, I think they should at least look interesting (..if we advertise Clonk beyond the border of the Clonk community at least)
However, I think to make decoration a perequisite for releasing (the public beta) is not wise at all. Obviously and comprehensible, this is a topic which just takes an unknown amount of time and thus especially cannot be "finished" along the way quickly before the release. IIRC the decoration was in any "todo till release" list that was published in the forum since the project started 1 1/2 years ago.
If we reach 1.0, it doesn't mean that any more features can be added, it just means that we have a playable, stable clonk version to build upon. Not a complete game. We may not forget that and we shouldn't allow any more delays to happen for that basic version. Perhaps other clonkers will also notice the bleak clonk landscape and if they care for Clonk enough, maybe they will help or even join us.
So, decoration? Sounds? Music? Graphics? Plants and trees? I'd love it. But it shouldn't delay the release.
Also, we don't have to make every tree, sound effect etc by ourselves, for stuff that can be included quickly, we can have a look at the models here:
http://opengameart.org/ or more here http://search.freegamedev.net/
>Perhaps other clonkers will also notice the bleak clonk landscape and if they care for Clonk enough, maybe they will help or even join us.
Yepp, I agree with that. But I would make it a prerequisite for advertising Clonk in non-Clonk communities, since that is where the first impression counts (maybe even not gameplay-impression but screenshot-impression)
So, public beta should not be delayed further by decoration. The first "advertised" release, on the other hand, should imo.
> So, decoration? Sounds? Music? Graphics? Plants and trees? I'd love it. But it shouldn't delay the release.
Well, either we are in feature freeze or we aren't.
But anyway, if the decoration includes anything new (e.g. for plants: reproduction and all that), I agree with you that this must first go only in Test.c4f.
> * Update system, Automatic release scripts and download links - Günther, Clonk-Carl, B_E(, Newton)
> How quick these tasks can be completed depends on the free time each one can and wants to spend on clonk, but my optimistic guess is that we can manage this in one week. When you reply to this post, can you please make a statement on whether/how this guess is realistic in your case (and if it is justified that I boldly assigned task(s) to you)?
I'll try, but I can't promise anything. There's still a few things to do.
I noticed during a conversation with B_E earlier that perhaps the procedure described on page two:
"[...] all rows which have the same platform as the one specified in the command are deleted from the table [...] All files that have been referenced by deleted rows must be deleted by the masterserver in both cases if delete_old_files is 'yes'" [...]
should function a little bit different. The reason is, that with the current concept, it is just not possible to to create different update packages for different from-versions (= making more than two requests per update) because the rows added on the first request are deleted again on the second. This odd logic in the masterserver can't be bypassed by the build scripts. Example:
?action=release-file&platform=win-x86&new_version=1.4.0&file=oc-win32-1.4.0.msi&hash=1238754345
<- installation file?action=release-file&old_version=1.2.4,1.2.6&platform=win-x86&new_version=1.4.0&file=oc-win32-1.2.4-1.4.0.c4u&hash=3981842046
<- updates from 1.2.4?action=release-file&old_version=1.4.0a&platform=win-x86&new_version=1.4.0&file=oc-win32-1.4.0a-1.4.0.c4u&hash=456568532
<- update from 1.4.0a to 1.4.0 overwrites the updates from 1.2.4 and 1.2.6
To fix this, on a new request not all rows which match the same platform should be deleted but only those which do not update to the newest version. (newest version = the version that has been given on the last request in the parameter new_version.)
I marked the change in the masterserver.pdf.
> Engine coders which are developing features (in branches), please don't merge them into the default branch but in a new branch.
I feel the necessity to point out that
default
will always stay the main development branch. All releases will branch off default
and live in their own branches, into which crash fixes from default will be cherry-picked, after we made sure that they won't regress anything.[Edit]
This means you should develop in
default
, and only cherry-pick very important fixes into the release branches. Don't do you dev work in a release branch please.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill