Date: Thu, 27 Jul 1995 20:19:14 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: jcargill@cs.wisc.edu (Jonathan Cargille) Cc: jkh@time.cdrom.com, hackers@freebsd.org Subject: Re: New 2.1.0-950726-SNAP available - come 'n get it! Message-ID: <199507280319.UAA02225@gndrsh.aac.dev.com> In-Reply-To: <199507280057.TAA08564@pongo.cs.wisc.edu> from "Jonathan Cargille" at Jul 27, 95 07:57:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Jordan K. Hubbard writes: > > Now available on freefall and ftp.freebsd.org: 2.1.0-950726-SNAP > > This supercedes the previous snap, 2.0.5-950622-SNAP. > > This SNAP naming seems to be getting a bit inconsistent; if > 2.0.5-950622-SNAP was a "post-2.0.5" snapshot, shouldn't > 2.1.0-950726-SNAP be a "post-2.1" snapshot? I currently have a proposal before Jordan that should clear this up once and for all, the way it is done now causes inconsistencies like this as that whole string was being provided on the command line, the proposal changes that so only the date is provided, the other parts come from the src tree of the relavent branch. Names (if Jordan agrees with the proposal) will become: X.Y-BRANCH: These are -current versions of the branch, and BRANCH currently has the values ``STABLE'' or ``CURRENT''. X.Y-BRANCH-SNAPMMDDYY: This is a snap shot on MMDDYY of one of the branches, it is turned on by a release engineering during snap shot building. Only the MMDDYY part is provided (and the change with use "`date`" to get that.) X.Y-RELEASE: This is a release, this requires a commit to build a proper release src tree so that things built with that src tree also say ``RELEASE''. This will appear briefly at the end of a -stable branch as the release is merged and such before -STABLE rolls up to the next version and all the numbers get bumped by the person doing the cvs ops such as tree tagging. [Humm.. perhaps the branch should be called ``STABALIZING'' :-)] The current tools put in place even allow us to continue to bug fix things in old releases (ie change to 2.1-BUGFIX-A) after a release is pressed and have it clearly ear marked as such. This is something we have never supported in the past, and may be looked at for the future, but the tools and mechanisms for doing it are in place, now it is a matter of resources (both man power and equipment) to make it possible. > Or is it just me? ;-) Or did I sleep through the 2.1 release? ;-) Well, -current is 2.2 now, and in the past that meant 2.1 was long gone. You sleep through a major shuffling of a few things right after 2.0.5, like the addition of a stable branch for doing the 2.1 work in, the fact that current will be releases as 2.2 when it is ready, etc. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507280319.UAA02225>