On Mon, Dec 08, 2008 at 07:16:51PM +0100, Corinna Vinschen wrote: >On Dec 8 13:00, Christopher Faylor wrote: >> On Mon, Dec 08, 2008 at 06:16:15PM +0100, Corinna Vinschen wrote: >> >On Dec 8 12:01, Christopher Faylor wrote: >> >> On Fri, Dec 05, 2008 at 12:07:33PM +0100, Corinna Vinschen wrote: >> >> >Btw., does anything speak against opening Cygwin up for public testing >> >> >on the Cygwin main list? >> >> >> >> I think it is a good idea but I'd like to start tracking 1.7.x like a >> >> normal release and increasing the x with each new release. That will >> >> allow us to figure out problems from source code more easily. >> > >> >I thought we stick to 1.7.0 until we create the first actual release in >> >which case we bump the version to 1.7.1. After that we bump every time >> >again, as in earlier releases. >> >> Does it really matter? > >Not in a technical sense. It's just the idea that the first official >release shouldn't be 1.7.24. 1.7.1 sounds much more neat :) > >> >Btw., when 1.7 is adopted, we will have to make release-2 an independent >> >directory again, right? Otherwise we will still pull in new 1.5 packages >> >which will have inferior features. >> >> I think that when 1.7 is adopted >> >> release-2 -> release >> release -> release-deprecated >> >> and we make setup.exe changes to accommodate that. > >I was just going to agree but ... does that work? The idea is that >people still using an old setup will get the old release. Since >"release" is fixed in old versions of setup, it might be more feasible >to stick to release-2 or to use something along the lines you suggested >at one point, like, say, "release-nt".
Ah, right. I wasn't thinking that people who had the old release might not want to update. Too bad we didn't have a mechanism in setup.exe to provide a warning to people before updating. So, release-2 becomes a first-class directory, setup.exe -> setup-deprecated.exe setup-1.7 -> setup.exe? cgf
