Date: Thu, 9 Oct 1997 13:53:48 -0500 From: Richard Wackerbarth <rkw@dataplex.net> To: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> Cc: stable@FreeBSD.ORG Subject: Re: Fwd: CVSup release identity Message-ID: <l03110703b062cdb61a4f@[204.69.236.50]> In-Reply-To: <199710091732.KAA03880@GndRsh.aac.dev.com> References: <l03110700b05eddbc3dc5@[204.69.236.50]> from Richard Wackerbarth at "Oct 6, 97 01:39:02 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
>> >On Mon, 6 Oct 1997, Richard Wackerbarth wrote: >You're only looking at 2 of many values, your making your decision based >upon incomplete information. Values of ``BRANCH'' (to be renamed FLAVOR >after the 2.2.5 release) are ALPHA, BETA, ..., RELEASE, STABLE, CURRENT. I view it in a slightly different manner. I agree that ``BRANCH'' is a poor term. I think that we agree that the BRANCHes are really 2.1, 2.2, 3.0, etc. I also agree that there are values other than STABLE and CURRENT. However, these values represent a PHASE of development. For example, Development (pre-release) Alpha (testing) Beta Released Patched might be terms that describe the situation. (I'm not arguing the names, just look at the concept). The important thing is that any given branch can have only one phase at any given time. Further, there is fundamentally nothing sacred about the transition from one phase to another. If you have continuous access to the development tree, the quality of the code immediately before the transition is the same as it is immediately after the transition. The only thing that is important about the phase is that there are some implied expectations and protocol restrictions on the developers which are organizational policy. In addition, there are certain snapshots of the development progression. These are called releases. Someone packages them up and distributes them to users. These users cannot change them (without creating something else which is no longer the same and therefore should not have the same name). Anyone who assembles a system between these named snapshots simply has a version of the branch based on its contents at the time the snapshot was extracted. The development phase is not important. Only the point on the development timeline matters. (Did you build your system from sources that were extracted before or after some change that was introduced at xxxxx?) >Now, tell me it can go away since you now have all the information and >I't will after the 2.2.5 release. > >> The "current" branch is presently called "3.0". > >Okay, I'll buy that, it means we can set FLAVOR == CURRENT instead of >FLAVOR == STABLE on the RELENG_2_1 and RELENG_2_2 branches. Now is that >ever going to confuse the shit out of users :-) Yep! Anyone who builds a system from the head of a branch is building the "current" version of THAT branch (current as of a particular time). In this context, "CURRENT" is meaningless. Rather, we should be DELETING both of these designations. The only value in identifying a non-release system with anything other than the timestamp is that it may be easier to remember that a change occured between a pair of named releases rather than remembering that exactly when it occurred. However, this only helps to exclude systems that fall outside the named bounds. Between the bounds, you still have to look to the more specific timestamp. My proposed nomenclature is to designate the branch, the last release tag along that branch, and the timestamp of the extraction. Communication about a particular branch would be identified by the branch and not by the flavor. I can see it now. As we are in aa alpha period, all discussion should be on the "alpha" mailing list. Next week, please move the discussion to the "beta" list... I don't think so. If we were a much larger organization and the "users" had access to ONLY the released versions of development, you might make an argument for it. However, we are too small and everyone has access to "today's" version. One list per branch should be sufficient. Richard Wackerbarth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03110703b062cdb61a4f>