Date: Thu, 2 Oct 1997 08:09:41 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: dg@root.com Cc: jkh@time.cdrom.com, andrsn@andrsn.stanford.edu, freebsd-stable@FreeBSD.ORG Subject: Re: CVSUP vs. SNAPS Message-ID: <199710021509.IAA28884@GndRsh.aac.dev.com> In-Reply-To: <199710021500.IAA20880@implode.root.com> from David Greenman at "Oct 2, 97 08:00:17 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> >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! > > The problem you're having is that the "2.2" release is actually called > 2.2.0 (that's what the tag is in the repository), so 2.2.5 is not going down. I didn't say 2.2.5 was going down, I said going from 2.2.5 BACK to 2.2 after release was going down. > We should perhaps make this more clear in the product literature, but I > really don't think that most people are confused over this issue. How about the fact that a 2.2.2 release occured, but somthing built from the bits on the 2.2.0 branch report via uname that they are 2.2-STABLE. That is going down! -- 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?199710021509.IAA28884>