The Lingo we should use

[Hallfiry]

I've noticed that it's often difficult to explain things or name them properly when we find them on media like cover disks or old ftp servers, when we explore the old gaming world. Thus I figured it might be useful to take one step back and discuss the whole thing from a meta perspective.

As an example that occurs to me pretty often, it's difficult for me to appropriately declare instances of demos, patches, pp on media. Since I'm often reading literature about linguistics I discovered it might be helpful to take a look at their terminology in order to properly speak about old games.
So to stop the chaos of "there's a version/copy/instance/variant/appearance/occurance/etc. on PC Gamer #3.1" I will now declare that record is the correct term to use.

As an example I'll show how I'd write about the preservation of Descent in my catalog :

Descent 1 was seemingly distributed in two different archive formats: hog and sow.
The catalog lists plenty of records of a descent.sow:
http://www.kultcds.com/Catalog/index.ph ... dn=&descr=
which split up into 5 versions
and even more records for descent1.hog and descent2.hog:
http://www.kultcds.com/Catalog/index.ph ... dn=&descr=
which fall into 7 versions.

PC Games 01/99 Bonus has an unrelated record of a file named Descent2.sow, that stems from a full version of Descent 2.

Next word that I also used above is stem (from), that I want to use for belong to/originate from/hail from/pp.

I'd be glad to hear more suggestions and also critique on my ideas for the words we should use.

[MrFlibble]

Very good idea! There is indeed a fine distinction we need for dealing with files from CDs which our currently used terminology fails to reflect, as you have described above.

It's a bit easier with online sources like FTP sites, because the files are zipped up in one or more archives, so we can just call it a "release". "Version" is already tricky/potentially ambiguous, because there may be different releases which are the same version (like those multiple Nitemare-3D releases), so I guess "version" should be reserved for what it was supposed to mean originally - a release which has a distinct number.

Now technically the term "release" can also be ambiguous. For example, MobyGames will treat CD-exclusive demo versions as "releases" which are associated with a particular magazine cover CD. I suppose that this also extends to full covermount releases as well. However if we have a downloadable demo/shareware/freeware game which was included on a covermount CD there is probably no reason to call any such instance a separate release, even though technically it was "released" on the CD media.

[Hallfiry]

[Rewritten:]

The term release is very difficult. I would personally use it for what I've mostly called variant up to now, which roughly sums up to:
"The original state of the record that was sent out from an authorative distributor."

Which means, the prerelease Demo of Diablo 1 in its exe version has 3(?) RELEASES: Win95 Sampler, Early Readme, Late Readme.
These are all the same demo, they only differ in details that we consider small enough to not justify a new version.
It does not matter where we find the instances of those, if we have any copies of them or if we have just postulated their existance.

-If you have a folder on your PC
-and it contains the things that were seemingly sent out by Blizzard as a batch to magazines
-in late august (not early august and not early september) of 1996
-then they are (unless you got them back then) a facsimile or maybe an editio[n]
-of a record (you had to get it somewhere obviously)
-of the Early Readme release.

Up to this point I have not specified what variant means and I think I'll keep that word undefined.

---

Additionally I decided to be not happy with the term stem anymore

[MrFlibble]

I think that to clarify what the terms refer to, we need to take into account that the might reflect two different (but ultimately converging) perspectives: one of a researcher who explores material in available sources, and another of the developers/publishers/distributors who go about their business releasing games.

I think it could be useful to first lay out the ideal theoretical situation from the developer/publisher perspective and then compare it against the issues we as researchers or collectors run into.

So let's imagine a hypothetical situation where a game is distributed only via authorised sources without third-party modifications, every release and version is announced and clearly marked as such etc.:

1. A developer decides to make their game available to the public in a certain form (demo, shareware, full version) via online download and/or as a publication on a magazine cover CD (or both). A version of the game will be built from source for this purpose. In most cases (I suppose in the majority of cases) this will not be the first build of the game produced by the developer, even if this is the first public appearance (it's not easy to find other words instead of release) of said game.

Side note: In order to avoid making up definitions where suitable ones already exist, I Googled a bit and found several sources which hopefully provide useful insights and/or clarifications to the matter:

Software versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software. [source]

Versioning is the creation and management of multiple releases of a product, all of which have the same general function but are improved, upgraded or customized. <...> Version control is the practice of ensuring collaborative data sharing and editing among users of systems that employ different versions of a product. [source]

In a programming context, a build is a version of a program. As a rule, a build is a pre-release version and as such is identified by a build number, rather than by a release number. [source]

For the last one, indeed build numbering is apparently quite often used to designate pre-release (~ pre-v1.0) "unique states" (this term seems pretty nice to me) of software, however I would suppose that the general meaning is that something compiled from source, be it a binary executable or a data file.

Historically, build has often referred either to the process of converting source code files into standalone software artifact(s) that can be run on a computer, or the result of doing so. [source]

There's also the term revision which refers to what we could also call version but from the point of view of a developer who edits the code:

A component of software configuration management, Revision control, also known as version control or source control, is the management of changes to documents, computer programs, large web sites, and other collections of information. [source]

From all this we can conclude that a very important concept for all these terms is that of 'change'. Indeed, if there were no changes between versions/releases then we would probably not require these terms at all.

Back to the hypothetical developer:

2. The build is probably tested and prepared for the release, which in the case of online distributions means uploading the game files in a format accessible to end-users to a website or FTP site. A readme is likely written to be included with the downloadable files and/or displayed online, which may have a certain date indicated for the release. This date may or may not coincide with the actual upload date and/or binary executable compilation date. The readme may also contain information about the version number or build number of the programme.

3. The build is packed up and uploaded for online distribution. After that the developer or the publisher probably announces the release via newsgroups, websites or otherwise. For magazine releases, the build it packaged and sent to the magazine publisher.

The result of this is a release of the game (Wikipedia suggests that it should be called Release to web), which in the hypothetical example coincides with version.

Switching to the researcher's perspective, we have to consider sources. If a release is obtained directly from the developer/publisher, that's the primary source (if published only through magazine coverdisks, they should be the primary source). Any third-party website/FTP or magazine coverdisk or CD compilation which have included the release that was obtained from the developer/publisher (or authorised magazine in some cases) should be considered secondary sources.

Because of this distinction, we need to consider complications that arise with each of these source types.

From the definitions quoted above, I'm getting the impression that technically speaking, the term version is indeed justified when the version number is explicitly indicated somewhere. It seems logical to use the term build when no version number is specified. Moreover, there are cases when several obviously different builds carry the same version number (e.g. Seven Kingdoms demo versions).

Another thing is when the developer or publisher "stealthily" updates a release without any announcement, usually to renew ordering/contact information etc. For example, we have identified three different sets of files which are all Descent II demo v1.0. I don't think Interplay announced these updates anywhere. This raises the question of whether these are different releases and/or different builds? It is my understanding that technically, if any files of a programme have been changed (in the case of Descent II demo, the splash screen image with the ordering information was replaced), this constitutes a different build, even if the source code revision (and the game executable) remains the same. I would probably suggest the term variant for this situation, but I'm not sure. Let's not multiply entities and use build for these cases. For instances with no build number available, it seems logical to use dates.

Official distribution may also take several forms. For example, Interplay provided both plain and self-extracting zip archives as distributions of Descent and Descent II demo/shareware. Additionally, there's a split-file version which comprises two floppy-sized zip archives. All these certainly constitute the same version but different distributions. Similarly, Epic MegaGames and some other developers/publishers have used plain-files zip archives for online distribution of their games, but apparently sent out installers to magazine publishers and/or shareware vendors. E.g. here's a version of Operation Carnage with a De-ICE installer on a PC Gamer CD: http://www.kultcds.com/Catalog/index.ph ... =$2FOcdemo
It also happens to be a slightly different build, although both releases (IIRC) are v1.0.

Here's another thing, also with Descent as example. Parallax/Interplay released patches to update Descent shareware from v1.0 to v1.1, and from v1.1 to v1.2. Each of these versions was also released as a stand-alone download. In v1.1, among other things, the splash screen with the ordering info was updated. Normally the screen is found in one of the data files (DESCENT.HOG), but the game can read a PCX image from its directory. So the v1.1 patch includes a PCX file, while the stand-alone shareware release contains an updated data file. So in fact you can get two different "builds" of Descent v1.1 shareware, either by installing a stand-alone version or using a patch on v1.0. Of course this should not really bother us as researchers because the answer is that there are two releases: shareware v1.1 and v1.1 patch.

However, this has implications for secondary sources, because a "patched" v1.1 can be found on CDs in unpacked form:
http://www.kultcds.com/Catalog/index.ph ... $2FDescent
http://www.kultcds.com/Catalog/index.ph ... ames$2F012
http://www.kultcds.com/Catalog/index.ph ... $2FDescent
http://www.kultcds.com/Catalog/index.ph ... $2FDescent

In fact, only two records of DESCENT.HOG with the size of 2,365,676 bytes in your catalogue are from a v1.0 Dec 22, 1994 build:
http://www.kultcds.com/Catalog/index.ph ... S$2FDESCEN
http://www.kultcds.com/Catalog/index.ph ... $2FDescent

We can expect a similar situation for v1.2.

Tu sum up, it seems logical to me to use the following terms:

• build as the most general term for any "unique state" of a compiled programme (or a single file); for a programme, all files required to run it in their entirety (expect for configuration files if they are not provided with the game) constitute a build;
• a version is a build which has a version number assigned to it; it might often need to be further specified whether the version in question is demo/shareware or registered;
• a release is a build/version which was made public either online or offline, and either as a stand-alone product or a patch; ideally, it should include an explicit license that grants the user rights to run this build on their hardware;
• a distribution is the form in which a release was made available to the public (zipped files, installer on a CD, zipped installer, self-extracting archive, split files etc.);
• a record I understood as an entry in your catalogue, but somehow I'm not sure if I'm right on this.

[Hallfiry]

THanks for your great assessment of the terminology!

[*]a distribution is the form in which a release was made available to the public (zipped files, installer on a CD, zipped installer, self-extracting archive, split files etc.);
[*]a record I understood as an entry in your catalogue, but somehow I'm not sure if I'm right on this.[/list]

Record and distribution are nearly the same. By record I mean a "preserved instance". So the term record is totally researcher-sided and referrs to any copy of "something" that we find. As records I also understand files that were preserved by archive.org. The term record also applies to things like screenshots, where we might have different records of one screenshot in digital form and printed form, etc.

[MrFlibble]

Got it, sounds good It should sure help describe the files dispersed through the various primary and secondary sources.

Record and distribution are nearly the same.

I guess then record is broader than distribution because we can apply it to individual files, whereas distribution can only be the entire set of files that make a single build/release.

I'm not sure if I like the phrase "build of a file" better than "version of a file". Surely the use of the term build is justified with binary executables and data files, however what if we have different readme files? I think that a "build of a text file" is somewhat artificial. Perhaps revision is a better term here?

BTW, there is at least one case when two builds (releases? distributions?) differ only by the readme files: that Powerslave demo you found a while ago on one of the CDs, which is also present as a split version at cd.textfiles.com.

[MrFlibble]

I'm not sure if I like the phrase "build of a file" better than "version of a file". Surely the use of the term build is justified with binary executables and data files, however what if we have different readme files? I think that a "build of a text file" is somewhat artificial. Perhaps revision is a better term here?

I've just realised that when talking about releases/distributions, we need to distinguish between the programme itself (which can and should be called a build), and the supplied documentation and/or auxiliary files which do not form any part of the programme proper. Readme files obviously fall into this category, so the Powerslave example above is not two different builds (since the game binary executables and data files are identical), but two different distributions/releases of the same build.

I've read somewhere that some Apogee (IIRC) registered titles relied on a copy protection method that would check the CRC of the FILE_ID.DIZ, which explicitly stated that the game is a registered version and should not be distributed publicly. Removing or editing the FILE_ID.DIZ would result in the game not working. That was supposed to prevent uploads of registered versions to BBSs. In this case, the FILE_ID.DIZ should be considered part of the programme of course, but otherwise it falls into the category of auxiliary files, alongside any documentation, preview screenshots etc.

That said, I think that the terms release and distribution need to be clarified a bit more:

• a release is a build/version which was made public either online or offline, and either as a stand-alone product or a patch; ideally, it should include an explicit license that grants the user rights to run this build on their hardware;
• a distribution is the form in which a release was made available to the public (zipped files, installer on a CD, zipped installer, self-extracting archive, split files etc.);

I would say that distribution can be defined as a set of files (either parts of a game or of an installer) which is packaged and/or recorded on physical media to be brought to the end-user. This includes the entirety of files, both those that constitute a build of a programme and auxiliary files, as well as packaging itself (if the developer/publisher chose to compress the release into a single file).

A release is then the set of files that constitute the game and its documentation, without the packaging. That way, we can talk about distributions altered by third parties (extra archive comments, added FILE_ID.DIZ or other documents, added or modified configuration files etc.), however the release remains the same nonetheless. I think that for cases when a third party removes part of the documentation for some reason, that should be treated both as an altered distribution and as an incomplete release. With DOS software, the developer/publisher would often supply a list of all files that form a release of the programme.

In other words,

• a build is a "unique state" of a programme; that is, all files necessary to run it, including binary executable, data and any auxiliary files; the other meaning is a "unique state" of a game file, either executable or data;
• a version is a build for which a version number is explicitly specified;
• a revision is a "unique state" of an auxiliary file (usually document) which is not part of the programme but is supplied with it;
• a release is a set of all files that the developer/publisher provides to the end-user as a single product; this includes a build of a programme and all documentation and other auxiliary files the user gets from the developer/publisher;
• a distribution is a release packaged in a certain way to be made accessible to the end-user via electronic or physical media; distributions can be altered by third parties, which is a common occurrence in secondary sources.

That way, for example, if we take the Epic MegaGames' use of online zipped distributions vs. offline installers, there may be the same release (and version) of a shareware game but distributions will be different. The same is with the different installers used by Apogee/3D Realms in different time periods.

Software catalogues and preview screenshots are a bit confusing, as to whether they should be treated as a part of a release, or a part of a distribution. It seems counter-intuitive to me to argue that pre- and post-1998 distributions of Apogee/3D Realms shareware games are different releases simply on the grounds that the old software catalogues and some preview screenshots were removed from them. Similarly, the offline version of Epic MegaGames' Highway Hunter includes a batch of preview screenshots from the registered game, which are not found in the online shareware version (although available as a separate download). The programme itself and all documentation is the same in both distributions.

[Hallfiry]

In other words,

• a build is a "unique state" of a programme; that is, all files necessary to run it, including binary executable, data and any auxiliary files; the other meaning is a "unique state" of a game file, either executable or data;
• a version is a build for which a version number is explicitly specified;
• a revision is a "unique state" of an auxiliary file (usually document) which is not part of the programme but is supplied with it;
• a release is a set of all files that the developer/publisher provides to the end-user as a single product; this includes a build of a programme and all documentation and other auxiliary files the user gets from the developer/publisher;
• a distribution is a release packaged in a certain way to be made accessible to the end-user via electronic or physical media; distributions can be altered by third parties, which is a common occurrence in secondary sources.

And again some rephrasing (or copying) and splitting:

• Build (A) means "unique state" of a programme; that is, all files necessary to run it, including binary executable, data and any auxiliary files;
• Build (B) and Revision mean "unique state" of a file.
• Version is a build for which a version number is explicitly specified.
• Release is a set of all files that the developer/publisher provides to the end-user as a single product; Including documentationa nd other clutter.
• Distribution (for better understanding you gotta pronounce that word as if it was Linux Distribution) is the unique state in which a publisher that we consider authorative enough (bbs, website, magazine, magazine publisher (e.g. Vogel Verlag, Comuptec, Future Publishing),...) made a Release public.
• Record is the unique state in which a File (or Files) is/are found on a medium. (Use it like the history term "written record")

I would suggest to call Build (A) Game Build (or Program Build if necessary) and Build (B) File Build or Revision (depending on which of both terms fits better.) The Game/File prefix can be omited where it is clear what is being talked about, of course.

[MrFlibble]

• Build (B) and Revision mean "unique state" of a file.

AFAIK, technically, revision can also refer to the programme as a whole (but more from a coder's perspective rather than a user's), however we probably don't want too many interchangeable terms that are synonymous, so I though revision would sound good with documents and such as a more general term.

[Hallfiry]

• Build (B) and Revision mean "unique state" of a file.

AFAIK, technically, revision can also refer to the programme as a whole (but more from a coder's perspective rather than a user's)

That would leave us with Game/Program Build and File Build both meaning the same as Revision, hu?
So we'll have to go with Game/Program Revision and File Revision, too, where Game/Program Revision is obsolete.

(OFF-TOPIC: I suggest using bold or underlined for highlighted words; and italic for stressed words; a highlighted term is stressed at the same time, but not vice-versa)

[MrFlibble]

Yes, it would:

There's also the term revision which refers to what we could also call version but from the point of view of a developer who edits the code:

A component of software configuration management, Revision control, also known as version control or source control, is the management of changes to documents, computer programs, large web sites, and other collections of information. [source]

To the best of my knowledge, revision and build (in the context of software development) describe the same thing, but from the perspective of source code and the compiled files respectively. It's just that also revision as a broader term can apply to documents and what not, while "build of a readme file" sounds strange/artificial to me.

What I have described above are suggested uses, not exhaustive descriptions of semantics.

[Hallfiry]

It's just that also revision as a broader term can apply to documents and what not, while "build of a readme file" sounds strange/artificial to me.

That is exactly why I couldn't leave the term revision away.
To settle this I'll now say a word of power:

Game/Program Build/Revision -> Program Build
File Build/Revision -> File Revision

The prefixes can be left away, but I would recommend not to do so unless it's obvious what one is talking about.

[Malvineous]

I agree that using "File Revision" makes sense, because as MrFlibble said, in the context of programming, "revision" refers to the source code, while "build" refers to the binary (.exe) files produced by build tools (typically a compiler.) Since the source code is a collection of text files, it makes sense to apply the "revision" term to other text files, like readme files. Typically in this case, confusion is avoided by using terms like "revision number" or "revision date", as opposed to "the revision" which is unclear whether you mean the revision of multiple files, one file, or a small revision (correction) inside a single file.

Microsoft refer to their prerelease versions of Windows by build number, and they include much more than just the .exe files, so it makes sense to refer to an entire game by build number (or build date.)

I think the use of the word "record" is not ideal though, as this word is already used extensively for talking about database records. In the context of a game, "record" implies a database or website entry about the game. Especially in Hallfiry's case, running a web site with lots of database records for game files, does "record" refer to the web entry or the file itself? For Hallfiry's intention of recording a unique state of a file, I think "instance" is a much better fit, as this word is already to describe a unique occurrence of something. For example in programming you can use a template to create many similar or identical objects, but each one of those is called an "instance". I think this fits in well with finding many copies of similar or identical files in different locations. You would have many instances of files, but hopefully only a small number of revisions.

The only thing I can see that is unanswered, is how to correctly label the v1.1 distribution of Descent, which MrFlibble says is different depending on whether you install the v1.1 distribution or the v1.0 distribution and then patch it to v1.1. If you install the v1.1 distribution that's fine, but what do you call the collection of files you get by installing the v1.0 distribution followed by the v1.0 to v1.1 patch? This isn't a "release" because it was never released like that, it's not a "distribution" as it was never distributed in this state. I suppose you could refer to it as the "v1.1 patch" version, which has no associated release or distribution?

[MrFlibble]

The only thing I can see that is unanswered, is how to correctly label the v1.1 distribution of Descent, which MrFlibble says is different depending on whether you install the v1.1 distribution or the v1.0 distribution and then patch it to v1.1. If you install the v1.1 distribution that's fine, but what do you call the collection of files you get by installing the v1.0 distribution followed by the v1.0 to v1.1 patch? This isn't a "release" because it was never released like that, it's not a "distribution" as it was never distributed in this state. I suppose you could refer to it as the "v1.1 patch" version, which has no associated release or distribution?

Yes, that's a good question I suppose that it would be a different build (because the set of files is different from the one obtained from the v1.1 installer) which is associated with but not entirely identical to the release of the v1.1 patch.

This "patched" build may become (and does become) a secondary-source (not original and not official) distribution in those cases when it is burned on shovelware CDs.