[X2Go-Dev] Bug#891: I have a fix for VcXsrv, but it needs discussion

Michael DePaulo mikedep333 at gmail.com
Sun Jun 28 17:35:07 CEST 2015


On Sun, Jun 28, 2015 at 5:10 AM, Stefan Baur <X2Go-ML-1 at baur-itcs.de> wrote:
> Am 28.06.2015 um 02:54 schrieb Michael DePaulo:
>> However, If I release X2Go Client 4.0.4.1 (or an update to
>> 4.0.4.0) with this fix, then sessions started on X2Go Client for
>> Windows 4.0.4.0-2015.06.24 and earlier can not be resumed on the
>> new version. This could be very disruptive to users.
>>
>> Does anyone have any thoughts on this dilemma?
>
> Don't we have the x.x.x.x versioning scheme for such reasons?
> Bump the version number up in a position that indicates "things may
> break" and all should be good, no?

I have asked people but I have never seen an official answer on what
our 4 digit versioning scheme means exactly.

I was under the impression that for A.B.C.D, it means this:

A - Major version with compatibility implications. As an example of a
compatibility implication, X2Go Server 4.x cannot accept connections
from X2Go Client 3.x unless x2goserver-compat is installed.
B - Major version without compatibility implications.
C - Minor version
D - Micro version (patch level)

I am also under the impression that a bump in A, B or C means that
"things may break", but not in "D".

Therefore, the 1st version of X2Go Client for Windows with this change
will be 4.0.5.0. We might release 4.0.4.1 before then, but it won't
have the change.

> Or could you create a patch that allows toggling between the two modes
> of operation, and when the first reconnect fails, try it with the
> other mode?

That's a good idea. I will need to add an option to VcXsrv like
"-[no]limitwglcolors", but that should be easy. I will look into this.

> - -Stefan
[...]

-Mike#2


More information about the x2go-dev mailing list