[crossfire] 2.0 release, was Re: Code restructuring

[Alex Schultz]

Mark Wedel wrote:
> Alex Schultz wrote:
>   
>> Andrew Fuchs wrote:
>>     
>>> Finally, i just want to note that our next release could be 1.10.0
>>> instead of 2.0 if we need more time for cf2.0.
>>>       
>> And that is something I strongly believe should be the case. I
>> personally do not believe that we are ready for 2.0 for a while (I'm
>> thinking about 6 months or so if not a little more), and I believe in
>> the meantime that we should do at least one release such as 1.10.0.
>> However I believe the point of another release between 2.0 and now to
>> gain more time, is fairly moot unless people can work on 2.0 in cvs
>> starting fairly soon, hence, I believe that the best solution would be
>> to create create a new cvs branch for working on 1.10.0, and then work
>> on 2.0 things in the main branch. In terms of debate between making a
>> branch for each major version, or each minor version, I personally don't
>> have much preference on, but I feel that a branch of some sort is
>> needed. Also, I believe the type of code restructure I mentioned a
>> little earlier on the mailing list, should be something to target for
>> 2.0, though I personally wait about a month to start work on it to allow
>> people to get used to usage of the branches and possibly to apply
>> pending patches that have been lying around for a while already.
>>     
>
>   Yes - a stable-1-x branch is needed.
>
>   One question not directly addressed on all of this are the different cvs trees.
>
> server: pretty clear on major/stable branching
>
> client: probably same thing (should the model be followed with client release 
> matching server release number?
>   
Personally, I think the major and minor version numbers should match,
but the micro should be independent, so long as we are releasing the
server and client at the same time still, and personally I think we
should continue doing that unless someone has a reason that separate
releases would be worthwhile.
> arch: Does this model make sense?  I suppose in some sense because as changes 
> are made, that may enable or change behaviour of archetypes.  What about new 
> archetypes that are release independent?
>
> maps: Basically same question applies are for arch.  However, maps could be more 
> a problem because patching/fixing maps could become very tedious.
Well, one issue is that changes in the server that might break the arch
format (i.e. separation of multi-meaning attributes), which could cause
problems unless we also create arch branches. The same also goes for
maps, despite the difficulties in patching/fixing maps.
The alternative though to separate branches, would be providing a
conversion utility for maps and arches, as map/arch breakage is often
easily convertible, with the server. Then apply that to cvs only when
the major release making that breakage, is released.
I'm not sure which of the options of branches, and conversion utilities,
I prefer, however I believe that one of the two would be needed.

Alex Schultz