Suggestion for release names?

Sat Feb 6 07:32:01 UTC 2021

     On Fri, 5 Feb 2021 01:39:54 +0100 Polytropon <freebsd at edvax.de>
wrote:
>On Thu, 4 Feb 2021 16:25:02 -0800, David Christensen wrote:
>> On 2021-02-04 03:11, Polytropon wrote:
>> > On Wed, 3 Feb 2021 13:34:30 -0700, @lbutlr wrote:
>> >> I know the subject of user confusion on STABLE and RELEASE has come
>> >> up in the past, but I found out that releng is also confusing as I
>> >> was recently talking to someone who only ran releng versions of
>> >> freebsd because he thought that was an English only version of
>> >> Release.
>> 
>> >> I know this is probably futile and there's little reason to change,
>> >> but I think all three animus could be better.
>> > 
>> > The "problem" is that those termini technici all carry a
>> > well understood meaning, 
>> 
>> > Even worse, if you try to do a mapping of
>> > 
>> > 	RELEASE-p<n>    |
>> > 	RELEASE         |          | home user
>> > 	PRERELEASE      |          | embedded
>> > 	RC<n>           | is to be | desktop
>> > 	BETA            | used for | server
>> > 	ALPHA           |          | tester
>> > 	STABLE          |          | developer

     STABLE used to mean that the kernal ABI remained constant throughout
a major release number.  However, AFAICT, that rule was broken two or three
years ago by the decision to import the LINUX Way of Doing Things (TM) for
graphics support, a decision which some view as having been forced upon the
FreeBSD graphics team, but which nonetheless has caused chaos ever since.
Somehow the NetBSD project has taken a different path, although I do not
know how they have managed that.

>> > 	CURRENT / HEAD  |
>> > 
>> > this will be very hard and probably won't work. ;-)

     [smirk]  To say the least.
>> 
>> I suspect that the terms chosen however many years ago have undergone 
>> shifts in meaning, which reduces understanding.
>
>I fully agree with that. However, a certain context must be
>understood as "known context", otherwise just choosing other
>words would be futile. And always keep in mind that those
>are intended for the english-speaking users - non-english
>languages are not even considered.
>
     With that my self-control has been overridden, so I will add some
"context" (a.k.a. "noise") to the discussion.
     A few of the above terms were in use long before UNIX of any kind
came into existence.  These terms were used by mainframe vendors, e.g.,
Burroughs, CDC, Fujitsu/FACOM, GE, Honeywell, IBM, ICL, NCR, and RCA, who
provided monitor system and operating system software for their mainframe
products, at least once the hardware was advanced enough to support such
software.  Naturally, operating system software was not a one-time thing,
but rather came in successive versions termed such-and-sundry "release"
each time a new version was issued.  Prior to new software being made
publicly available, the vendors would issue "alpha" releases to be used
*strictly in house* by installations within that vendor corporation.
(The tor project, for example, does not follow that tradition.  It calls
what other folks would term "beta" releases as "alpha".)  After extensive
in-house testing of new versions of software (and not just operating
system software), a beta release would be issued to a select few customers,
usually with very large installation bases, on the basis of signed, written
agreements that the software was provided on a strictly test basis with no
liability on the part of the vendors with the further agreement that the
users of such beta releases would attempt to document any and all problems
encountered with the test software to the vendors, so that the vendors might
track down and fix the problems before generally releasing new versions
to their user bases at large.  The beta-test period might last from several
months to over a year.
     In the case of OS/360, for example, releases were normally just given
integer numeration.  There were exceptions, however,  My earliest encounters
with OS/360 were with release 13, although I had been given quite a few
SRL manuals for release 11 for my own use by an IBM SE.  In those days,
there were still very loud, legendary echos about OS/360 release 9, which was
followed by 9.5, 9 1/2, and 9.55 before users had finally lowered their
screaming to levels IBM thought it might survive.  (9.5 and 9 1/2 were, it
was made clear to me, even by IBMers, distinct releases.:-)  Prior to that
there had been release 5, which, IIRC, could not complete the IPL startup.
The details escape me at this remove, but it was thought of as another of
IBM's major screwups.  Of the operating systems of the other major vendors
I know nothing from those days, except that only Honeywell and IBM put forth
hardware and operating systems that supported virtual memory (Multics and
TSS/360).  Soon after, Cambridge University issued CP-67/CMS as the world's
first virtual machine facility.  In the IBM line, I don't know, for example,
what the extensive 70xx processors had for operating systems, if any, or
whether they only had monitor systems.  Somebody older than I is invited to
fill in that gap.  The 1620 and the 1710 control systems had stand-alone
support and a disk-based monitor system, of which I used the appropriately
named Monitor I for three years or so.  AFAIK, that latter software only
had a single release, which included the SPS-II assembler and the FORTRAN
II-D compiler and processed a super-simple set of job control statements.
     In any event, the concept of a "release candidate" was assumed in the
idea of a "beta" release.  After fairly extensive testing by the restricted
set of beta users and the ensuing patches, the fixed version was released.
IOW. a beta release *was* a release candidate.  Beta sites were *very*
restricted.  I don't recall ever meeting anyone who claimed to be a beta
user for IBM software in those days.
>
>> I think people could better deal with vocabulary if they had a better 
>> understanding of the FreeBSD release engineering process and its 
>> deliverables.

     Yes, this is also true.  However, the problem remains that a new user
of FreeBSD has not spent several months reading the available documentation
and conducting experiments based thereon and therefore is confronted by a
learning-curve mountain that he must grok before he can have had time to do
so.  Further, if said user comes from a background of one of the other
BSDs, he may be fooled by their differing software life cycles.
>
>Still misunderstandings could arise. For example, CURRENT
>seems to suggest (!) that this is the most recent version
>of FreeBSD - shouldn't you install that? But in fact it is
>a development version. Also STABLE could be misunderstood
>as an attribute that this version is stable, while in
>reality RELEASE-pX (patched version) would be that kind of
>software.

     A fair point.  A better name, for example, might have been -DEVEL or
something similar.  After all, that sort of naming can be seen extensively
throughout the ports tree.  Or, perhaps, something like -FUTURE. ;-)  (Or
maybe even -FUTURAMA. %-D )
>
>As I sometimes tend to say: FreeBSD's release engineering
>process is like a distillery: from CURRENT / HEAD through
>STABLE to RELEASE. ;-)
>
>But of course this is not a one-way "reduction" process,
>because from HEAD or STABLE, security patches can be
>generated, and they can also be ported back to older
>versions which are still supported, so an "older release,
>patched version" could be more up-to-date than a "newer
>release, point-RELEASE dot zero". The whole concept of
>the release engineering process could be illustrated
>in a way that the meanings of the "tags" become clear.
>
>I don't know if it is possible (or desired) to change
>the naming, but that might also be a chance to provide
>easier ways of understanding to those who do not know
>the context of historically grown termini technici
>within the FreeBSD realm...
>
>
>
>> Michael W. Lucas in "Absolute FreeBSD", 3 e., pp. 422-427 [2], discusses 
>> "FreeBSD versions".  Figure 18-1 is very helpful:
>> 
>> -  The trunk is labeled "FreeBSD-current".  I believe this corresponds 
>> to -CURRENT deliverables [3].
>> 
>> - Two branches are shown -- "FreeBSD-stable 13" and "FreeBSD-stable 14". 
>>   I believe these correspond to -STABLE deliverables [4].
>> 
>> - There are dashed lines marked "Improvements" from the trunk to the 
>> branches.  I believe those that arrive at numbers -- 13.0, 13.1, 13.2, 
>> 13.3, etc. -- correspond to -RELEASE deliverables [5] and those that do 
>> not correspond to patches.
>> 
>> 
>> I suggest adding a similar diagram to the FreeBSD website, supplemented 
>> with explanatory text.
>
>Excellent idea. This way, the termini technici used are put
>into the correct context.
>
     Yes.  However, it should be carefully reviewed for errors and omissions.
A history of UNIX chart is included in FreeBSD somewhere, though at the
moment I don't seem to be able to find it.  That history, however, is very
incomplete and possibly incorrect in some places.  For example, NEXTSTEP does
not appear in the chart at all, not even in the Mac OS history, although it
was the foundation for all that ensued following Steve Jobs's return to
Apple.  And NEXTSTEP was a descendent of 4.3BSD and 4.4BSD UNIXes with the
kernel modifications of CMU's Mach versions 2.4 and 2.6.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************