[crossfire] Release?

[Mark Wedel]

On 03/20/10 12:55 AM, Nicolas Weeger wrote:
> Hello.
>
>>    Yes, that is the ideal case, especially if there is lots of active
>> development.
>>
>>    If there isn't, it is simpler to just freeze the trunk gate for anything
>> but bug fixes needed for the 1.50 release.  That way quality can get
>> better, without the overhead of a branch, potentially needing to do merges
>> (a fix in trunk needing to get in for the 1.50 release or vice versa), etc.
>>
>>    The other thing is we don't typically make patches a release, so the
>> branch isn't that useful in that area - instead, we just say it will be
>> fixed in the next release.  If we do releases on a regular basis, that
>> isn't that bad.
>
>
> Well, I can see quite many things in the pipe lately - healthbars being one,
> and other fun things coming.
>
> So totally freezing trunkmay not be a great idea, or it should be really a
> short time period :)

  Yes, in the past, usually for a week or two.

  Of course, there is nothing that prevents one from making a branch from 
something other than the latest version.  So if tomorrow, someone made a lot of 
big changes in which you think 'hmmm - I'd like more testing before and don't 
want them in this release', someone could make a branch for 1.50 from right 
before that commit.

  That doesn't eliminate the issue of now having two branches to update when 
making a fix (presuming the fix is not related to that commit, but something 
unrelated which needs to be fixed in both releases)

>
>
> If we are still thinking of end of march, what should be done right now?

  In general, complete things that are not completed, and fix bugs.

>
> AFAIK the Windows build works (more or less), so I could produce a version if
> needed.

  That would be good.  I'm never sure about the demand for the server, but 
demand for the client still seems there.  a release of the JXclient should also 
be done (just to make it more readily available).  I'm not quite sure what a 
release of the jxclient means - presumably a precompiled .jar file in one, with 
a source release for the others (similar to how the client has a source release, 
as well as some binary packages for specific OS's).  But I'd think in the case 
of the jxclient, that 'binary' release should be platform independent, but I 
could be wrong on that.