Date: Thu, 2 Oct 1997 06:58:03 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: andrsn@andrsn.stanford.edu, freebsd-stable@FreeBSD.ORG Subject: Re: CVSUP vs. SNAPS Message-ID: <199710021358.GAA28556@GndRsh.aac.dev.com> In-Reply-To: <3503.875779067@time.cdrom.com> from "Jordan K. Hubbard" at "Oct 2, 97 00:57:47 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > Thanks--also thanks to John Polstra. I got the sources after the > > "freeze" time and did a make world and built a new kernel, but it > > still says 2.2-STABLE, so I wasn't sure. > > It will say 2.2-STABLE at all times unless there's a specific release > in progress, then it will be set to that release name for all of a day > or so before going back to 2.2-STABLE. Please, not again, don't duplicate the errors of your past handling of this. The sequence of commits should be something that creates 2.2-STABLE (where we are today) 2.2.5-BETA (for while we are in BETA on the branch) 2.2.5-RELEASE (when you finally roll the puppy up) 2.2.5-STABLE (after you roll the release). Going DOWN in version numbers is not something I would call good release engineering/customer relations work. If you go back to 2.2-STABLE I have know way to know that the person has something before the 2.2.5 RELEASE point. You did this in the 2.1 branch when I proded you to change the word ``RELEASE'' to ``STABLE'', but your commit also changed 2.1.5 back to 2.1, _decreasing_ the version number, again I iterate, version numbers should never decrease! -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710021358.GAA28556>