On Sun, Jun 28, 2015 at 5:10 AM, Stefan Baur <X2Go-ML-1@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