Hi,
I was wondering what the Cygwin community thinks about maintaining
backwards compatibility, especially regarding configuration files when
updating or changing a package. As a long time Debian user I have grown
accustomed to upgrades going very smoothly, backwards compatibility
Greetings, Laurens Blankers!
I was wondering what the Cygwin community thinks about maintaining
backwards compatibility, especially regarding configuration files when
updating or changing a package. As a long time Debian user I have grown
accustomed to upgrades going very smoothly
experience matters.
Before you ask, yes, I did post this to the cygwin-xfree mailing list.
However I am not getting anywhere there. So I am interested in the thoughts
of the wider, beyond X11, Cygwin community on backwards compatibility.
As I mention in my response to the cygwin-xfree thread you're
the Semantic Versioning
spec, fix the problem and release a new minor version that corrects the
problem and restores backwards compatibility. Even under this
circumstance, it is unacceptable to modify versioned releases. If it's
appropriate, document the offending version and inform your users
Laurens Blankers wrote:
I noticed that updating to the latest xinit (1.3.4-1) from the previous
one (1.3.2 I believe) completely breaks existing configurations.
What about changing the way X server is started? I flagged here:
https://cygwin.com/ml/cygwin-xfree/2014-11/msg00040.html
my
On 30-12-2014 13:46, Angelo Graziosi wrote:
What about changing the way X server is started?
I could change the way I start X, and I have successfully gotten things
to work by doing so. But that is not my point. My point is that I need
to make significant changes to the configuration to get back
Laurens Blankers wrote:
Then I drag the X icon to my
Start-up folder, so that it starts every time my desktop boots
The same you can do with the link created as suggested in my previous
replay. When I had Win XP I did that way for almost 7 years without
tacking care of any configuration
On 30-12-2014 17:04, Angelo Graziosi wrote:
The same you can do with the link created as suggested in my previous
replay.
You are probably right, but again, that is not the issue. The point I am
trying to make is that breaking configurations which have worked for
many years in a patch release is
Just to close the loop on this subject: Corinna more or less convinced
me that breaking backwards compatibility isn't a good idea at this
time.
So, I've introduced the previously-mentioned kludge into cygwin sources.
So, recent snapshots have reverted to the slow method for filling out
command
Just a thought
Since this could potentially cause some misunderstanding, what about
bumping the Cygwin DLL version number to 1.6.0? That way there could
be some sort of statement to the affect that apps requiring these
functions should be relinked with 1.6.0 when it's released. It's
of
maintaining backwards compatibility but we've already broken that once
in recent memory with the case of pure Windows environment variables so
I think we probably will just take the logical next step and break
things for WinMain and GetCommandLine as well.
If there are a lot of programs out
realize that this is a major departure from previous stated goal of
maintaining backwards compatibility but we've already broken that once
in recent memory with the case of pure Windows environment variables so
I think we probably will just take the logical next step and break
things for WinMain
program to work with Cygwin 1.5.20 then you'll have to relink it. I
realize that this is a major departure from previous stated goal of
maintaining backwards compatibility but we've already broken that once
in recent memory with the case of pure Windows environment variables so
I think we
Igor Peshansky wrote:
If GetCommandLine lives in libcygwin.a, then programs linked on older
versions of Cygwin will not link that function in, and thus won't work
with the new DLL. Programs linking with the new version of Cygwin will
have that function, but due to API changes, may not work
On Mon, 10 Apr 2006, Brian Dessent wrote:
Igor Peshansky wrote:
If GetCommandLine lives in libcygwin.a, then programs linked on older
versions of Cygwin will not link that function in, and thus won't work
with the new DLL. Programs linking with the new version of Cygwin will
have that
On Mon, Apr 10, 2006 at 02:52:04PM -0400, Igor Peshansky wrote:
On Mon, 10 Apr 2006, Brian Dessent wrote:
Igor Peshansky wrote:
If GetCommandLine lives in libcygwin.a, then programs linked on older
versions of Cygwin will not link that function in, and thus won't work
with the new DLL. Programs
On Tue, 11 Apr 2006, Christopher Faylor wrote:
On Mon, Apr 10, 2006 at 02:52:04PM -0400, Igor Peshansky wrote:
On Mon, 10 Apr 2006, Brian Dessent wrote:
Igor Peshansky wrote:
If GetCommandLine lives in libcygwin.a, then programs linked on older
versions of Cygwin will not link that function
which has
had no other changes is going to pull in a new function from the cygwin
DLL even after recompiling. The only way I can think of that that could
happen is if a macro in a header file changed or we introduced a
backwards compatibility redirect in libcygwin.a.
A program which is using WinMain
a non-linux-like interface.
So, I'm thinking that if you want your WinMain or GetCommandLine using
program to work with Cygwin 1.5.20 then you'll have to relink it. I
realize that this is a major departure from previous stated goal of
maintaining backwards compatibility but we've already broken
19 matches
Mail list logo
