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 From: Chris Faylor Date: Mon, 22 May 2000 19:19:37 -0400 To: cygwin-developers AT sourceware DOT cygnus DOT com Subject: Re: Next net release will be 1.1.3 Message-ID: <20000522191937.B14279@cygnus.com> Reply-To: cygwin-developers AT sourceware DOT cygnus DOT com Mail-Followup-To: cygwin-developers AT sourceware DOT cygnus DOT com References: <20000522172249 DOT A10159 AT cygnus DOT com> <200005222150 DOT RAA31092 AT envy DOT delorie DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200005222150.RAA31092@envy.delorie.com>; from dj@delorie.com on Mon, May 22, 2000 at 05:50:13PM -0400 On Mon, May 22, 2000 at 05:50:13PM -0400, DJ Delorie wrote: >> It makes sense to "increment by two" for each net release. This means >> that if someone downloads a snapshot (which will be something like >> 1.1.2, 1.1.4, etc.) they'll be able to upload to 1.1.3, 1.1.5, etc. ^^^^^^ upgrade > >Is this just to avoid someone downloading a snapshot and being >confused about what version it is? I'd rather somehow tag the >snapshots as being snapshots (i.e. version is "1.1.1+20000522" rather >than just "1.1.1"), not wasting a version number on them. It is because I want people who are already using 1.1.2 (i.e. the current snapshots) to be able to update using setup. Setup won't consider it an update if they already have 1.1.2 on their systems. >I suspect people will get confused if the next release isn't 1.1.2. I >think the version number in the sources should be changed to reflect a >real release, which means we can't just repackage snapshots any more. >More work for us, but it seems like the right thing to do. The last release was not a repackaged snapshot. I have a script which prepares a net release. People seem to be able to accept that setup versions are not incremented monotonically. I don't think it will cause undue stress to increment net releases by two once we have aligned on an even boundary again. Basically, I think that what is currently 1.1.1 should have been 1.1.2. >> The only slight inconsistency in this plan is that it is the opposite of >> the "stable releases are even, beta net releases are odd". Since it's >> likely that few people besides DJ and I are aware of this even/odd >> relationship, I'm wondering if this is a big deal. > >It's the middle number that counts, not the last number. 1.1.* are >all "odd" for that purpose; the next CD-ROM releases will be 1.2.* I wasn't talking about the middle number. I understand the numbering scheme that we (or rather Linus Torvalds) settled on. cgf