Release perequesites
Coordination: N/A
Essential for release
- An installer/rpm/deb has to be set up, minimum for Windows and Linux (distris). Also, the DX redistributable must be installed automatically within the installation if the DLL is not available yet (for the Windows installer).
- The complicated(?) update-system needs to be fixed and set up to enable the download of patches/updates of the newest release
- On first start, the player automatically needs to get a new player with a default control set with whom he can immediately start to play [already the case?]
Hm, I can't remember whether I posted this already or not: I talked to a friend of mine who happens to be a Debian developer. To meet their policy we should also ship everything in the "preferred way for modification". For the engine that's the source code of course, but this also applies to graphics where it would be desirable to ship the 3D models in blender format, and 2D graphics as photoshop/xcf/whatever was used to generate them. That can be in a separate tarball.
Most models in the repository are in .blend format, few are in C4D-format I think.
They should just be shipped in whatever format they were created and can be edited easily.
I suggest we stay away from official repos untill 2nd or 3rd big release (untill some real content is shown - because current game is too far away from the thing CLONK should realy be).
Official repos are usally only managed by a few poeple. So it's their decission when to include it. However, I guess it would be better to have some good "marketing" from the begginning. People attract people, and these people could may be developers, you know?
Yeah, I thought about marketing too. Just didn't consider adding packege to the repo as an effective marketing move (we waited for the last Debian distro (Debian 5 Lenny) for 18 month and I can not tell when the next distro will be ready. Probably no one will add any additional packages until the next big release - at least I would not). I am not a an expert in marketing that is why I would not make any suggestion on how we should promone OpenClonk though...
in the official Repos, there are many projects still under developement, that's opensource!
the earlier we get in, the better openclonk will be spread.
the earlier we get in, the better openclonk will be spread.
Since not everyone know this yet, I will write in the public thread this time.
I already have an OpenClonk RPM file and it works fine on RPM-based Linux distributions (at least, on latest versions of them). The mechanism is a bit buggy though and needs some polishing (see the respective post), but it will do for our first release.
Concerning question about adding it to the repositories... I doubt that. Current mechanism (mentioned above) does not allow to update files effectively (currently we have to remove package
As for DEB file... I won't be around here till 24th of April so I will probably not have time to create it (or will I? - that depends on the release date which is, AFAIK, is yet undefined).
I already have an OpenClonk RPM file and it works fine on RPM-based Linux distributions (at least, on latest versions of them). The mechanism is a bit buggy though and needs some polishing (see the respective post), but it will do for our first release.
Concerning question about adding it to the repositories... I doubt that. Current mechanism (mentioned above) does not allow to update files effectively (currently we have to remove package
rpm -r openclonk
and then install it again)... But again... I do not think this is needed for our first release.As for DEB file... I won't be around here till 24th of April so I will probably not have time to create it (or will I? - that depends on the release date which is, AFAIK, is yet undefined).
If the file is created by a script, maybe you could make that available so it can run automated on openclonk.org? (just to pass the Joel Test on that point ;))
It is CShell script. How do I run it on OpenClonk.org?
EDIT: the process of creating RPM is rather complicated. You have to
1) Have rpm and rpm-build packages (applications) installed on your Linux system
2) Create a bunch of directories
3) Pack your source into a tarball
4) Copy it into source directory
5) Write a specification file
...
And so on. It can be done ONLY on Linux system in the Linux environment.
EDIT: the process of creating RPM is rather complicated. You have to
1) Have rpm and rpm-build packages (applications) installed on your Linux system
2) Create a bunch of directories
3) Pack your source into a tarball
4) Copy it into source directory
5) Write a specification file
...
And so on. It can be done ONLY on Linux system in the Linux environment.
Can you check the script into the repository? I can run it on the same machine which does the nightly builds if desired.
Here is a first try for the Windows installer based on the CR installer script: http://londeroth.org/~ck/oc_win32.exe
This does not yet install a DirectX redistributable. It seems that CR did not either. If we don't get DirectX working until the release then I'd suggest to simply build the engine without it to circumvent the problem for now. Also if any artist feels like it we could make use of an individual logo and welcome image for the installer (see the two empty bitmap files in tools/install and compare with the CR installer).
Do you think it would be a good idea to also provide the weekly development snapshots with an installer instead of a zip file?
This does not yet install a DirectX redistributable. It seems that CR did not either. If we don't get DirectX working until the release then I'd suggest to simply build the engine without it to circumvent the problem for now. Also if any artist feels like it we could make use of an individual logo and welcome image for the installer (see the two empty bitmap files in tools/install and compare with the CR installer).
Do you think it would be a good idea to also provide the weekly development snapshots with an installer instead of a zip file?
> This does not yet install a DirectX redistributable. It seems that CR did not either.
CR a) used DX8, which is already installed on XP, I think, b) didn't need one of those d3dx*.dlls. Those are likely to be missing if the user only had an older DX9 installation.
I'd guess that if and when somebody invests the time to make DX work again, he or she will also invest the time to make the installer execute the DX web installer.
I didn't test your installer but in any case I suggest that you put the script to create the installer somewhere into the repository.
Could be nice to test the installer. Otherwise it is not important. Also, if we provide an installer, the misunderstanding that the snapshot is some kind of release could arise. I think we should only have installers for releases + subreleases.
>Do you think it would be a good idea to also provide the weekly development snapshots with an installer instead of a zip file?
Could be nice to test the installer. Otherwise it is not important. Also, if we provide an installer, the misunderstanding that the snapshot is some kind of release could arise. I think we should only have installers for releases + subreleases.
> I didn't test your installer but in any case I suggest that you put the script to create the installer somewhere into the repository.
It is already: tools/install/oc.nsi
Bugs and single issues in the bugtracker
Essential for release
Bugs, issues and single features which are essential for the release in the bugtracker are marked as "urgent" (two red arrows up).
Direct link to all release related issues (marked as urgent)
Sounds
What about them? We should compile a list of missing sounds.
Well, anybody up to that task of creating such a list? I'd suggest that this list will be posted into the sound studio then.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill