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

[Chris Faylor <cgf at cygnus dot com>]

On Mon, Jul 03, 2000 at 09:39:03AM +0200, Michael Ring wrote:
>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)

What directory structure changed heavily between 1.1.1 and 1.1.2?  What
applications "refused to run"?  1.1.1 actually fixed a lot of problems
that were in 1.1.0.  The only problem with it, that I am aware of, was
the binmode/textmode stuff.

1.1.3 has Corinna's fixes to avoid accessing the network, which should
speed up things for some people.  That's why we're trying to get it
released.

>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:

The "binary incompatibility" that has been introduced is no different
than what we have done before.  Newer versions of cygwin1.dll will
still work with older binaries.

If it is a tremendously huge deal, I can "fix" the library code to make
it backwards compatible.  I usually tend to adopt a "wait and see" attitude
for this kind of thing, though.  It may be a big non-issue.

>(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.

The older versions of packages are always available in the "old"
directory.

>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.

It is a colossal, large asteroid sized wish that there will be
volunteers available to do this.  We have only about four people
actively contributing anything to the cygwin DLL right now.  DJ,
Corinna, and I already have to worry about various Cygwin releases in
our full-time jobs.  I doubt that any of us wants to add something like
a "stable" branch to the mix.

If this change to libcygwin.a causes massive heartache on the cygwin
mailing list, I will fix it.

I don't want to muddy the waters with a "supported" and "experimental"
branch three months after the release of 1.1.x.  We're still fine tuning
how we are doing things.  I'm trying to make up for the time that we
lost during the relatively static B20.1 period.

Eventually things will either settle down or someone will implement the
site that you're talking about.  I doubt that DJ, Corinna, or I will
be the ones setting it up, though.

cgf