Time for something other than cygwin/latest ????

[Michael Ring <Michael dot Ring at T-Mobil dot de>]

In the last weeks some ideas were discussed that may cause
binary-incompatibility. 

The question is if it does/does not make sense to split off a 'release
version' of cygwin before development continues. I know this is a
support nightmare but I think it would be worse to generate a
user-nightmare. I want to describe the 'user-nightmare' in more
detail:

Cygwin is a moving target at the moment.

Version 1.1.0 was o.k. but not perfect
1.1.1 was much worse than 1.1.0, some applications refused to run
1.1.2 seems to work fine; Problems in 1.1.1 resolved automagically
(But directory structure changed heavily)

Applications also changed in a rapid fashion (gdb, ash, inetutils) and
created huge traffic in the cygwin list. (But yes, they got better
from release to release)

Binary incompatibility creates a new problem:

(Hypothetic) example:

Someone is happy with cygwin, the way it is now (I could understand
this, works great for me at the moment)
gdb gets updated based on the new (incompatible) library. The only
chance to get it is to upgrade to 'latest'.

Upgrading to latest solves the gdb problem but introduces a new
problem in another application, he got during the update to latest.
Good for the user if he has a backup of the old version, bad if not
because then there is no way back.

So here's the idea (not new, saw it on the list before):

Create a new cygwin dll based on 1.1.2 (or whatever is good for the
purpose) and name it 1.2.0 (like in linux, even numbers at the second
position in version declare a version stable) and move cygwin + apps
to that folder.

Continue development with 1.3.0. (As latest)
I know, this means branching in cvs, but I think it is the better
solution.

Perhaps there are also volunteers out there in Internet that are
willing to support the stable release so that the cygwin core team can
concentrate on developing new features. Upgraded applications could be
built against the stable codebase once they are prooven to be stable.

This would provide a stable codebase for professional use of the
cygwin dll and still give everybody the chance to move to latest if
there is a need; (And also a way back to the stable release)

How do you all think about that ?

Greetings,

Michael