2.) Release management:
a.) if possible, everybody should annouce the changes he would like to do and what time he "thinks" he need for it. A very rough estimation is more than enough. Then he synchronizes his local SDk with the one from SpoiledFruits server and start wotking on it. When he finished his implementation and testing (!!!) he looks for the files he changed, checks them out from Spoiledfruits server, merges the versions and checks them in again. As already mentioned, this should be quick operation.
b.) from time to time we should decide to make a release. That means, the current version will be closed for implementation and will go into a test phase. We need that test phase, because there may be conflicts between some packages.
c.) After internal test phase is fnished, we do an official release (beta or alpha) which is put on Source Forge for public download.
d.) The new release is then base for the next loop starting again at point a.
In general this is more or less the typical release cycle of a software :
- specification phase,
- implementation phase,
- test phase,
- release