Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com Date: Fri, 12 May 2000 17:26:02 -0400 Message-Id: <200005122126.RAA19789@envy.delorie.com> From: DJ Delorie To: cygwin-developers AT sourceware DOT cygnus DOT com In-reply-to: <20000512171353.A2947@cygnus.com> (message from Chris Faylor on Fri, 12 May 2000 17:13:53 -0400) Subject: Re: A riskier alternative to "latest"? References: <20000512171353 DOT A2947 AT cygnus DOT com> > This is similar to a lot of other projects so I don't think this is a > very radical concept. The only thing I don't know about is what to name > the directory, actually. Is "development" clear? Some projects call it > "dontuse" or "new", too. DJGPP uses "alpha" and "beta" subdirectories for stuff like that; we don't get too many complaints (I don't remember *any*), but the install tools don't scan those directories anyway. They key is to not install the test versions *by default*. If setup doesn't go more than one directory deep, we could add alpha/beta directories within each package. Or, we could add alpha/beta siblings to latest; setup should ignore those also. I think the concept of alpha/beta is pretty well understood. I don't see why we'd need to invent some other term. Alpha is for things that probably won't work, beta is for things that probably will work, latest is for things that do work. Another option is to allow tagging individual tarballs with "risk factors". To do this we'd need either a rock-solid versioning/naming scheme, or start using some master config file for setup to read, so that setup could prompt for "do you want to try experimental versions?" and do the right thing. Of course, we'd need a way to revert to stable versions if they break.