public inbox for
help / color / mirror / Atom feed
From: Laurens Blankers <>
Subject: xinit-1.3.4-1: breaking backwards compatibility
Date: Tue, 30 Dec 2014 11:07:00 -0000	[thread overview]
Message-ID: <> (raw)

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.

The changes have been mentioned in the release announcement:

And numerous posts have since reported bugs regarding these changes. For
most a workaround has been provided, except for the 'icon in the
taskbar' issue.

I would like to express my wonder and dismay that such a seamingly minor
version change includes functionality which completely and utterly
breaks many, if not most, existing configurations. I am not sure what
versioning strategy is being used for Cygwin/X but I would like to call
attention to the semantic versioning standard (currently version 2.0.0):

Signalling this major change by increasing the major version number of
the xinit package (e.g. 2.0.0) would have made it a lot clearer what the
impact of the change would have been.

I would also like to call attending to the following FAQ item from the
same website:

Q: What do I do if I accidentally release a backwards incompatible
change as a minor version?
A: As soon as you realize that you've broken 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 of the
problem so that they are aware of the offending version.

I would like to kindly request that this change is reverted, at least
until the time that a proper and documented upgrade path is available.

Now please don't take this the wrong way. Although I realize some
probably will. I do appreciate all the time that everyone, and not in
the least Yaakov, invests into maintaining Cygwin/X. However as a user
and software engineer myself I also very much appreciate systems
continuing to function after minor upgrades.


Laurens Blankers

Unsubscribe info:
Problem reports:

             reply	other threads:[~2014-12-30 11:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-30 11:07 Laurens Blankers [this message]
2014-12-30 12:46 Angelo Graziosi
2014-12-30 13:42 ` Laurens Blankers
2014-12-30 16:04 Angelo Graziosi
2014-12-30 16:07 ` Laurens Blankers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).