Digital editions can change long after publication: errors can be corrected; new materials can be added; the scholarship can be updated. The fact that such changes can occur on an ongoing basis is both one of the great potentials and one of the great terrors of digital scholarly resources. Printed books are comparatively static; while students of bibliography know that changes to books can and do happen in the course of a print run, in most circumstances readers instinctively recognize G. Thomas Tanselle’s “central truth . . . that books are not meant to be unique items and are normally printed in runs of what purport to be duplicate copies” [Tanselle 1980, 18].[1] Moreover, printed volumes are self-identical: a single copy of a book remains the same object and carries the same text unless acted upon by outside forces, like the environment, natural deterioration, or a human hand. Standards for scholarly citation, which solidified around print resources, take advantage of this objectual stability. Referencing a book means identifying its author and title, its edition number (if specified), and the details of its publication (perhaps including the year of its most recent printing or issue). Where the details of a particular copy matter (for instance for incunabula, or where the argument is bibliographic), the writer might go so far as to specify a library or archive and shelfmark. Armed with that information, readers can find and consult an appropriate copy.

By contrast, online digital resources can be expanded or corrected long after their initial release[2] — not necessarily by publishing a new edition that can occupy the shelf beside the previous, nor even through a stop-press correction that will affect volumes printed after it is made, but simply by updating some files on a webserver, with the result that anyone accessing the resource from that point on will see the revised form. Indeed, this mutability is one of the defining promises of digital textuality. Jerome McGann, in his influential essay “The Rationale of Hypertext” (first published online in 1995), contrasts the physical book, which “literally closes its covers on itself” when it is published, with the hypertext archive that “need never be ‘complete’” and “will evolve and change over time, it will gather new bodies of material, its organizational substructures will get modified, perhaps quite drastically” [McGann 1995] [McGann 1996, 27, 29]. Less poetically perhaps, but no less significantly, errors can be corrected with relative ease. And anyone who has tried to maintain a digital resource over any duration knows that, quite apart from willful content revisions, changes may not merely be possible but required in order to keep it operational.[3]

While the open-endedness of digital resources, the potential for evolution and infinite expansion, has excited scholars (the creators of large digital editorial projects among them), the inherent changeability of digital materials also poses threats to the scholarly ecosystem. Looking beyond the by now well-known problem of link rot, in which online resources linked in references simply disappear from the internet, research on science communication has identified the problem of context drift, in which links function but the content on the website has changed since it was referenced [Klein et al. 2014]; a study published in 2016 found that as many as 75% of webpages referenced in scholarly literature in Science, Technology, and Medicine have changed since they were cited [Jones et al. 2016]. Though results would likely be different if examining citations of digital scholarly editions, which are my concern in this article, the issue of context drift highlights the problems that digital mutability poses to the scholarly record. Indeed, the Committee on Scholarly Editions of the Modern Language Association (MLA CSE) has identified “the challenge of maintaining the scholarly ability to be referenced in view of the ways that interfaces change over time” as a central issue facing digital scholarly editions [MLA Committee 2016, 7].

In this article, I focus on digital scholarly editions, arguing that in order to make sure such editions are citeable and their history is intelligible, their creators and publishers must assign version numbers in tandem with any changes made to edition content. By digital scholarly editions, I refer to any electronic resources that encode textual objects for scholarly study.[4] While the same considerations might apply to many kinds of digital scholarly resource, I choose to focus on digital editions for a few reasons. For one thing, perhaps more than other areas of digital scholarship in the humanities, digital scholarly editing constitutes a clear community of practice, with a longstanding tradition of editorial theory and a widely (though certainly not universally) shared technical standard in the form of the Guidelines of the Text Encoding Initiative (TEI). For another, the concern with textual histories within scholarly editing and other fields under the umbrella of textual scholarship suggests that editors of all people ought to be particularly attentive to the way textual resources transform in time.

But perhaps most significantly, digital editions occupy a hybrid position in the scholarly ecosystem that makes it especially important to be able to identify and track the changes they go through and the states in which they exist. Digital editions, as I understand them, are simultaneously scholarly publications and data sources. Like all scholarly editions, digital editions are a product of interpretation, scholarly judgment, and the imposition of codes and conventions onto the material being remediated; that is to say, they are works of scholarship, produced according to the research and critical judgment of their creators. Like other scholarly publications, digital editions can be formally vetted through peer review processes.[5] And in general, digital editions are presented in user interfaces that support the reading and study of the provided text, rather than simply providing encoded files for a user to download.[6] But editions also provide data on multiple levels. Most basically, they provide texts corresponding to particular documents or works that scholars may reference and cite in publications, treating the edition as a surrogate for the object it edits and using the text it offers as a basis for analysis: that is, as data.[7] Humans are by no means the only potential consumers of the data embedded in digital editions. Texts and metadata can form raw material for analysis, including computer-aided study and incorporation into large corpora. And the dream of the fully networked digital edition, functionally integrated and cross-referenced by other editions and systems, grows ever more practical with the development of shared infrastructures and standards.[8] Digital editions, then, are simultaneously publications and data, potentially offering interfaces both to humans and to machines, and it is essential that these multiple consumers be able to understand the evolution of digital editions and precisely reference different states as editions are revised.

Version numbers, I argue, offer a simple and practical method not merely for identifying a state of a resource, but for communicating something of its history and the relationship among its states. Yet defined, citable version numbers still seem to be a rarity in the world of digital editions, and no consensus practice exists in the field regarding how different versions of an electronic textual resource should be identified, or what it is that version numbers should communicate.[9] Although textual scholarship has created sophisticated frameworks for understanding revision and the evolution of texts, I suggest that software developers have much to teach editors about versioning living resources in ongoing development and publication. This essay argues that a new version number should be attached each time an edition is updated, that version numbers should communicate something meaningful about the scope of changes to the resource, and that the encoded informational content of an edition should be versioned separately from the interfaces through which users access that information. After outlining considerations involved in assigning version numbers, I conclude with a case study of the development of a versioning policy for the Piers Plowman Electronic Archive, a longstanding scholarly resource that has published editions of multiple texts in evolving formats.

The fundamental changeability of digital resources, including digital editions, poses challenges to longstanding scholarly paradigms of authority and completeness. Kathleen Fitzpatrick has suggested that the capacity — indeed, in some circumstances, the necessity — for digital writing to change over time might suggest a fundamental change in our understanding of scholarly writing, from product to process [Fitzpatrick 2011, 66–72]. But new paradigms only slowly beget the practices needed to support them. Paul Fyfe has argued that we have not sufficiently theorized how digital scholarship deals with the problem of error [Fyfe 2012]. Correcting error is relatively simple, but scholarly practices surrounding correction lag behind.

For digital editions in particular, change is a double-edged sword. Although few editors would now claim to be producing “definitive editions,” the goal of any editor is presumably to produce an accurate text representing the document or work being edited according to that editor’s theory of the object of study.[10] Thus, the ability to incorporate corrections and continuously present the most accurate possible text in one sense enhances the reliability and scholarly value of digital editions by contrast to print, where errors discovered after publication can be corrected only in later printings or by issuing errata. But that same flexibility underscores the need to be able to clearly identify particular states of the resource. Consider a scholar who bases an argument on a particular reading taken from a diplomatic text presented in a digital edition. The editors later discover that they have made an error in their transcription and update the edition. Without a way to identify the specific state of the resource when it was cited, the error may appear to have been the scholar’s, and the scholarly record is muddled. Similarly, archivists seeking to preserve a digital edition can more effectively capture its history if the resource clearly signals when changes occur. And computer systems that ingest and process data from digital editions (for instance aggregating texts from multiple publications, or analyzing the text of an edition and recording statistical information in a database) have the same needs as human researchers: to know in what form they have accessed a resource and when changes have occurred. Citation styles, clerical practices, and technical measures have all attempted to offer solutions to the problem of digital change, but I argue that explicit versioning of resources can more effectively meet the needs of digital reference.

When citation guides were first faced with the problem of the mutability of digital resources, some suggested that researchers citing online publications should include in their citations the date on which they accessed the material [Gibaldi 1995, §4.9.1] [Turabian et al. 1996, §8.141] [Gibaldi 1998, §6.9.1] [Publication Manual 2001, 4.16.71ff].[11] Access dates recognize that online resources evolve, but they are concerned with a researcher’s activity (visiting a website) rather than with the resource itself. Unless a resource happens to have been archived on that particular day, a date of access does not point to a particular form of the material (and there is, of course, no guarantee that the resource did not change later on the day it was cited). The Chicago Manual of Style accordingly suggests that “access dates in online citations are of limited value” and does not recommend including them in citations [Chicago Manual 2017, §14.12]. And for computer systems interacting with a resource, recording the date of last access does nothing to determine whether it has changed since that last access.

Another way of dealing with the problem of mutating resources — the method most endorsed by the TEI, and the most widely used way in which digital editing projects appear to deal with textual change (see Appendix) — is manually creating a log of revisions. Attaching revision metadata to files allow records of revisions to be closely associated with the files themselves, though this information does not make it possible to reference particular states of the text. The TEI Guidelines provide the XML element <revisionDesc> in the header of each file to record narrative explanations of changes and the reasons and agents behind them in individual <change> elements associated with each revision [TEI Consortium 2019, §2.6]. Because change logs are simply written records of modifications, they are not tied to the TEI, or to any particular metadata format. The Walt Whitman Archive's [Folsom and Price n.d.], for example, maintains a public change log in the form of a blog that provides clear descriptions of modifications to the Archive, from corrections of typos to pervasive metadata updates [Walt Whitman Archive Changelog 2019].[12] Individual XML files also carry the TEI <revisionDesc> element. The Whitman Archive’s approach models thoroughness and transparency in disclosing ongoing modifications to a digital resource. But the Archive largely obscures these revision histories from users of the site. The change blog is hosted at a different web domain from the Archive itself, and the revision lists embedded in file metadata are not displayed in the reading interface provided on its website — probably the context in which most users will encounter the texts. In contrast, the William Blake Archive [Eaves et al. 2017] extracts this revision history and presents it in a human–readable format in an Electronic Edition Information section associated with each object in its collection. This section of the display makes the file history more directly available to readers conducting research within the Archive and conceivably allows readers to cite the date of the last revision, but still does not supply a specific identifier pointing unambiguously to a particular state of the file. The many editorial projects that use change logs store and expose that information in a wide variety of ways, but share an interest in recording what kinds of changes were made, when, and (often) by whom — without necessarily offering a way to reference a state of the resource resulting from a particular set of changes.

Nor do change logs offer any way to get back to prior versions of a resource; a user can understand what has changed, but not access an earlier form. The increasing embrace of revision control systems (RCSs) such as Git in the digital humanities has suggested the possibility of automated, systematized methods for tracking revision history and providing access to specific states of a project or file.[13] Elena Pierazzo proposes that RCSs should be embedded in digital edition software, exposing the evolution of an edition and providing access to previous states [Pierazzo 2015, 185–186].[14] Wiki-based editions, such as A Social Edition of the Devonshire MS [Siemens et al. n.d.], are one existing model enacting Pierazzo’s hope for editions with built-in RCSs. Christian Wittern goes even further, suggesting that distributed RCSs such as Git might furnish a new ecosystem for scholarly publishing of digital editions, allowing the maintenance of fine-grained revision histories as well as the coexistence of multiple revisions of a single file carried out by different scholars [Wittern 2013, §4].

RCSs make file history accessible, but do not necessarily identify or make intelligible meaningful developmental stages. While different RCSs provide different features, broadly, they operate by storing the content of each file as well as a precise record of each change made to any file. As a result, all changes are reversible, and it is possible to retrieve any previous state of a file as it was stored in the RCS repository, as well as any previous state of the repository as a whole. In order to facilitate retrieving earlier states, RCSs do (unlike change logs) provide unambiguous identifiers for a particular state of a file. In Git, for instance, each commit has an associated hash: a cryptographically generated key that can be used to identify and retrieve a particular state of the repository. A particular version of a file, or of the whole project, can thus be identified through an associated hash. However, they are not necessarily meaningful to human users. Git hashes, produced using the SHA-1 algorithm, take the form of forty-digit hexadecimal numbers (usually cited only by their first few digits). The hashes of successive commits bear no visible relationship to each other; indeed, given two hashes but no access to the repository containing the data, it is not possible to determine which represents the more recent state of the data. Other RCSs use different mechanisms, some of which are more straightforwardly numeric, but identifiers within RCSs are inevitably tied to the details of the system and may not correspond to human editors’ understanding of their processes. They cease to identify states of a file or resource if that file is archived elsewhere, or even if the project migrates to a new RCS.[15]

Revision control is an important tool for data management in the digital humanities. But explicit, deliberate versioning of data should go beyond recording revision history or providing an arbitrary identifier for a particular state of a file (bound to a specific RCS). Versioning should communicate information that helps both humans and computers understand how that version relates to others and the context in which users should approach it. Assigning version numbers to digital editions would permit humans and computer systems not only to refer to a particular state of the edition, but to understand the relationship between any two copies. Adopting clear versioning practices aids both the preservation and the reuse of data, and the producers of digital editions can benefit from practices developed both in the fields of textual scholarship and software development in producing useful version numbers for digital editions.

The problem of versioning data is by no means unique to digital editions; it is a pressing issue of research data management and publication across disciplines. The W3C recommendation on “Data on the Web Best Practices” highlights the importance of versioning data and specifically indicates the value of standardized, meaningful version numbers that not only identify versions, but suggest how they differ [Lóscio et al. 2017, §8.6 and Best Practice 7]. But despite increasing recognition of the importance of clearly versioning research data, standard practices around versioning have yet to cohere in the research data community; a guide to data versioning from the Australian National Data Service is replete with language like “no agreed standard or recommendation” and “no one way” [Australian National Data Service n.d.]. Still, emerging data infrastructures support a move toward more transparent and explicit versioning. For instance, the research data repository Zenodo introduced support for versioned Digital Object Identifiers (DOIs) in 2017, allowing depositors to update their data and permitting researchers to cite both specific versions and a whole concept independent of version [Nielsen 2017].[16] Particularly within the Open Science movement, the growing emphasis on data publication has translated into attention on data versioning.

However, the textual digital humanities, and digital editing in particular, have been slower to adopt versioning practices. Editors’ awareness of the problem of textual variance should make them more attuned to the need to track and publicize the evolution of their own editions. The practices of textual criticism point to the value of developing versioning protocols for digital editions.

When textual scholars use the term version, they mean something different from (though related to) the way the term is used in software development. Because my argument that digital editions need versioning policies lies at the intersection of these fields, it will be useful to survey the ways in which the two fields think about versioning. Literary scholars and textual critics might speak of the Quarto and First Folio versions of Shakespeare’s King Lear, or the A, B, and C versions of the fourteenth-century alliterative poem Piers Plowman — or to distinct draft versions produced during the course of Thoreau’s revision of the single manuscript of Walden. Software developers (or users), on the other hand, might refer to version 5.2.1 of the Linux kernel, or to Apple’s iOS 12.4 (eliding the word “version” entirely). Do these concepts have anything to do with each other? Though their orientation is different — textual scholarship is focused on historical analysis, software development on ongoing maintenance, publication, and support — both fields share a common concern with making it easier to understand variation and evolution, a concern likewise relevant to the problem of changes in digital editions.

“Version”, as used by textual critics and editors, generally denotes a distinct state of a work or a document that has transformed in time. Literary works exist in different versions because of alterations during the course of their composition and transmission — alterations by the author or by someone else, willed or unwilled. So, a campaign of authorial revision of a work would produce a new version of that work, as might the copying of a medieval manuscript in which a scribe introduced changes (even unintentional ones), or the publication of an expurgated edition long after an author’s death. These versions have independent value as forms in which creators conceived and audiences encountered the work. Donald H. Reiman in 1987 argued for what he called “versioning”, as a counterpoint to editing: rather than producing complicated, expensive critical editions, he suggests, it may be more productive to publish accessible texts of major forms in which a work existed, such as important editions and authorial manuscripts, allowing readers to compare the texts themselves [Reiman 1987]. (The profusion of digital documentary editions suggests that Reiman’s dream is increasingly being realized.)[17]

Both genetic critics and those concerned with the “sociology of the text” have emphasized the coherence and vitality of individual versions of developing works, pointing to the inadequacy of the notion of final authorial intention and calling for editorial and critical engagement with versions as coherent units.[18] Hans Zeller argued that individual variants in witnesses to a work cannot be considered in isolation, as had been common under the principles of eclectic editing; rather, we must recognize “the relationship of its elements to one another and to the whole, and therefore to what constitutes a text as a text, to what makes it into a particular version” [Zeller 1975, 237]. Peter L. Shillingsburg identifies the concept of version as “a means of classifying copies of a Work according to one or more concepts that help account for the variant texts or variant formats that characterize them” [Shillingsburg 1991, 50]. A version is thus a concept, not a thing; it is distinct from any physical embodiment (which might not represent it reliably), and versions come into being through the act of reading, as readers create them to organize textual variants [Shillingsburg 1991, 51, 73]. John Bryant, articulating his concept of the “fluid text” defined by the flow among different versions, echoes the notion of versions as “critical constructs” but also emphasizes their relationality: all versions exist in relation to other versions; they come into being through revision (which may or may not be intended); they are “pulsings of . . . collective energy” that can involve both authors and the editorial and cultural forces surrounding and following them; they have their own conceptions of the work and speak to their own readerships [Bryant 2002, 88–90]. While these and other theories of the concept of version differ on points such as the precise degree, nature, and agency of the changes that can produce a new version, they share a sense that versions are distinct and alive, and their coexistence is part of what constitutes a work.

These sophisticated frameworks for textual change may seem far from the problems of labeling changes as a digital edition is revised, and from the straightforward numerical approaches that I will draw from software development. But textual-critical accounts of versioning remind us that readers (and, we might add for our purposes, machines) encounter individual texts as coherent units, and these discrete forms have existence and meaning independent of the work as a whole. The kind of versioning this article focuses on is not teasing out key moments in the life of a work that is the object of study, but identifying moments of change in the evolving life of the published edition. In other words, echoing Hans Walter Gabler’s understanding of the contents of an edition, this article is concerned with versioning the editor’s text and the editorial discourses attached to it [Gabler 2010, 45]. An edition might present one or more versions of a work or of a document (indeed, the ability to present more versions in more dynamic forms has long been heralded as one of the most exciting potentials of digital editions), but what I address in this article is the need to version that edition as an edition, to keep track of the changes that occur within the edition itself.[19] Versioning, as I use the term, means assigning version identifiers to public materials as they develop; it is a publication practice rather than a critical practice.

That leaves the practical problem (unresolved by textual-critical theories of versions, which focus on more complicated analyses) of how to communicate the state of the edition to its users, whether humans or software programs. Existing publishing practices a not great help. Print publication simply has not developed conventions for describing ongoing revisions. Minor errors discovered after printing might be dealt with by issuing a list of errata; a more thorough revision might occasion the publication of a new edition. This publishing logic features in the closest the TEI Guidelines come to addressing the versioning of texts. The <editionStmt> section of the TEI header groups together information about an “edition” of a TEI-encoded text [TEI Consortium 2019, §2.2.2]. The Guidelines link the intellectual foundations of the concept of edition to the idea of a “master copy”, while simultaneously noting that the concept does not really apply to electronic texts. Nevertheless, the primacy of the print concept of edition leads the Guidelines to distinguish between “substantive changes” (such as the encoding of new information throughout the file) and “minor changes . . . which do not amount to a new edition” (such as error corrections or conversation between encodings) — a distinction that the Guidelines themselves acknowledge to be somewhat arbitrary and subjective. These “minor changes” can be recorded in <revisionDesc>, but there is no mechanism for labeling them. Confusing the issue still more, the Guidelines treat edition as synonymous with version, level, and release, while using the terms revision and update for minor changes below the level of edition. Finally, the Guidelines offer two rather different ways of recording version information in the same element. The edition (or version) can be recorded either descriptively, with a phrase like “new edition” as the content of the <edition> element, or with a “formal identification (such as a version number) for the edition” in the @n attribute. The Guidelines introduce a concept broadly similar to the print concept of edition, but one that lacks the technical underpinnings (the setting of type) that gave the concept its meaning in print, and that lacks the expressive power for dealing with digital textuality in a comprehensive way.

The shortcomings of the TEI’s print-inspired model suggest that we might look elsewhere for models to describe changes in computer-encoded data files with sufficient granularity. The field of software development has, over a period of decades, developed software version numbers as a system of practice for tracking the development of complex, digital objects — pieces of software — as they are published and revised. Software version numbers also situate the objects they describe in their developmental histories, but from the inside: rather than analytically describing objects after the fact, they are assigned during the development and release process to track ongoing work. Software version numbers facilitate many kinds of reference: they track changes to a piece of software, help users know when updates are available, facilitate technical support by unambiguously identifying a particular state of that software with all its particularities, and promote interoperability by allowing computer programs to determine whether they are compatible. Despite its straighforwardness, software versioning is a rich signifying practice, and it offers a model that suggests practical solutions for editors of digital editions.

Version numbers, at their most basic, delineate stages in the development of an object — for instance, a piece of software — by quantifying them and assigning ordered numbers to the object. It would be possible in principle to use a single whole number, which increases with every change. However, this approach, which fails to distinguish the scope of the changes that have been made, is insufficient for dealing with complex software objects. It is instead common practice to subdivide the version number into parts according to the scale of the difference from what has come before. The most common approach is to segment the version number, using a period to divide the parts. Version numbers with either two or three segments are common. A piece of software with version 2.7.4 would thus signify major version 2, minor version 7, revision or patch 4.[20] (The meanings of the first two numbers are typically major and minor version; what, exactly, later numbers communicate is less consistent, though they often indicate small revisions intended to fix errors without adding features or altering behavior.)

The meanings of these sequences are not fixed; different software creators are free to construct their version numbers in different ways, and there are no universal criteria for distinguishing major and minor releases — although some recent efforts, which I will discuss, have attempted to make version numbers more systematically intelligible. But broadly, major version releases are likely to introduce significant changes to a product: for instance, a new user interface, a large set of new capabilities, or technical changes that make files produced with the new version incompatible with previous versions. Minor versions might introduce features that do not substantially alter the nature of the product, or correct problems that have been discovered. Smaller releases, like patches, are likely to fix individual errors.

This way of conceptualizing versions is at heart hierarchical, with each level in effect “containing” those below it. In general, bumping the version number at any level resets all the levels below it to zero, so that, for instance, the major release that follows 2.4.7 is given version number 3.0.0. Conceptually, the life of a major version consists of all the releases under that major version number, not just the original point zero release. This hierarchy roughly parallels the way the edition–impression–issue–state model subdivides the bibliographic object (see Bowers (2005), 37-42, 406-411; Tanselle (1975)). An edition, in bibliographical terms, is created whenever a given text is typeset; setting new type constitutes a fundamental change in the essence of the object even if the text remains unchanged. A new edition is a kind of new major version, an object that on some level shares identity with what came before but also represents a significant break. Other categories are grouped beneath this, expressing different levels of identity change with an edition subdivided into impressions (the copies printed at once) and impressions divided into issues (copies intended as a unit of sale) (see Tanselle (1975), 28n14). Sheets of books even get “patches”, changes correcting individual errors; in his attempts to distinguish issue from state, Fredson Bowers suggests that minor textual corrections, along with small supplements, produce only new states and not new issues because they are simply “delayed attempts to construct an ‘ideal copy’”, much as software patches do not seek to extend functionality or change intended behavior but merely make the software conform to existing expectations [Bowers 2005, 67].

The point, of course, is not that software versioning and bibliographic description map the same procedures to different media. Each practice is informed by different practical needs, disciplinary contexts, and underlying technologies. Rather, I wish to point to a broad correspondence in approach between the two procedures, even though they bear different relationships to their subject matter: both organize intellectual objects hierarchically, categorizing and subdividing around questions of essential identity and of imagined ideal state.

But bibliographic classification, as an analytical practice, is rooted in the evidence of specific changes. Software versioning, by contrast, has been accused of being arbitrary and inconsistent — and at times of being driven by market forces rather than technological logic. A few efforts to make versioning practices more consistently meaningful help clarify what version numbers can actually assert about an object.

One approach to versioning software, which has been called Calendar Versioning, highlights the temporality of releases [Hashemi 2019].[21] This approach recognizes that knowing when a software object was released may be the most important way to identify and evaluate it. Microsoft has offered the most widely visible version of this practice, with releases like Windows 95, 98, and 2000. (It is worth noting, however, that these are merely public release names and the software actually carries a different version number distinct from the release name.) But a variety of other software uses Calendar Versioning in less dramatic ways: the Ubuntu Linux distribution, for instance, offers what look like fairly traditional version numbers, but the first segment of the version numbers is the last two digits of the current year, followed by the month, so that as of the time of writing, the most recent version (released in April 2019) is 19.04. This approach has appealed to at least one digital editor; the texts edited by Jeffrey C. Witt from Peter Plaoul’s commentary on Peter Lombard’s Sentences carry version numbers that employ a form of Calendar Versioning, as detailed in the Appendix.

In emphasizing date as what identifies an object, calendar versioning resembles scholarly citation practices, which emphasize publication dates, and sometimes access dates — although calendrical version numbers clearly and uniquely identify particular resource states, as access dates do not. Calendar Versioning privileges temporal sequence above all else; it suggests that when an object was produced is the most salient information for assessing it. It also establishes a sequence of versions, chiefly by relating them in time. Thus, Calendar Versioning is effective for allowing users to assess the age of a particular resource, to understand which versions were produced earlier and later, and to determine whether a more recent version is available. But it does not indicate not scope: it is impossible to tell from version numbers alone whether two versions are differentiated by the correction of a minor error or by a significant overhaul.

Even generic versioning practices have tended to make the degree of difference among versions greater than in Calendar Versioning, differentiating major and minor versions according to the relative degree of change. However, these approaches have appeared inconsistent to some critics: different developers or companies make different decisions regarding what constitutes minor and major versions, and these decisions are sometimes driven by market forces as a new major version might generate excitement or drive customers to upgrade. The Semantic Versioning specification, created by Tom Preston-Werner, is an attempt to specify rigorously and technically what version numbers (or, more precisely, what changes in version numbers) actually mean [Preston-Werner n.d.].[22] I will dwell slightly longer on Semantic Versioning, because it has provoked a debate that exposes a fundamental question not merely of how versions should be identified but what versioning is for — a debate that helps expose for the creators of digital editions the role that versioning practices might play in communicating with the public and interfacing with larger systems.

Semantic versioning is based on the traditional [major].[minor].[patch] format, but attempts to codify something largely implicit but inconsistently practiced in community practices for giving version numbers to software: that the different portions of a version number reflect different kinds of change. Semantic versioning is most concerned with libraries and packages (that is, pieces of software designed to be used by other pieces of software), and specifically with what are called their APIs (Applications Programming Interfaces): the formal methods through which other programs interact with the package. (It is worth noting, however, that the Semantic Versioning specification is itself semantically versioned; the application of these principles is not restricted to packages or libraries.)

Semantic Versioning is primarily concerned with whether changes to a package break backwards compatibility. That is, have you changed the way your API works so that the same command, issued to the new version, will produce different results? The central principle is that any breaking change to the API (that is, one that will cause the same command to have different results) is a new major version. A release that adds new functions while maintaining backwards compatibility is a new minor version, while a patch version is one that simply fixes bugs, provided the fix does not break backwards compatibility. Semantic versioning is designed especially for use with package managers, programs that can automate procuring and updating the packages needed to build or run a piece of software.

Semantic Versioning sits especially uneasily at the intersection of intellectual and mechanistic understandings of versioning. Jeremy Ashkenas, an influential JavaScript developer and vocal critic of Semantic Versioning, argues that the system “prioritize[s] a mechanistic understanding of a codebase over a human one. . . . It’s alright for robots, but bad for us” [Ashkenas 2015].[23] Ashkenas suggests that, in an environment where other developers may write source code relying on a project’s bugs, the definition of a “breaking” change is subjective — a point others contest. Perhaps most significantly for Ashkenas and other detractors, small function changes might under Semantic Versioning require an increase in the major version number (say, from 2.3.1 to 3.0.0) — a change that implies a major rethinking of the software that may not, in fact, exist (and can cause version numbers to balloon). Ashkenas agitates in favor of what others disparagingly call “Sentimental Versioning” and he playfully labels “Romantic Versioning”: a system under which a developer’s understanding of the magnitude of the change and the relationship between versions defines the version number.[24]

The crux of the debate around Ashkenas’s rejection of Semantic Versioning, which riled a community of developers whose projects were affected by an update that Ashkenas declined to label a new major version, is whether version numbers are intended for human or machine consumption. Software processes that decide whether it is safe to update a given library do not care what a developer’s sense of the change is; humans, on the other hand, may be misled by seeing a major release that actually consists of a conceptually minor change.

Why should scholars at the intersection of physical book study and digital scholarship be concerned with a four-year-old squabble among software developers, much of which involved how developer practices integrate with automated systems? The Semantic Versioning debate is particularly interesting for digital textuality because it draws attention to the different kinds of weight that version information can carry, and the different systems into which it integrates. Software developer Niels Roesen Abildgaard has attempted to nuance the Semantic Versioning debate by suggesting that software exists on a continuum between interfaces directly with users and interfaces exclusively with other software; user-facing software, like games or (to a lesser extent) desktop applications, is most suitable for Romantic Versioning, since human understanding is paramount, while software libraries would benefit from Semantic Versioning because relatively few humans will look at them directly, but they will often be included in other software systems [Abilgaard 2015]. The Semantic/Romantic debate draws our attention to the fact that version numbers provide an interface for understanding software changes, and that this interface is conditioned by purpose and audience: a key insight for considering how users of digital editions might interact with version numbers and what information they can convey.

The focus on versioning as a communicative interface, designed to work in a system with a clear audience to satisfy a defined purpose, helps us understand the complexity of digital editions as objects to be versioned. Digital editions operate within multiple systems at once. They are typically created first and foremost as objects for reading, to be studied closely by individuals. They are also sources of data, furnishing both character data and metadata that can be manipulated and analyzed in a variety of ways. And they are objects of citation, which must be unambiguously referenced in scholarly environments. McDonough et al. point out that people using and analyzing digital objects for different purposes may have profoundly different (though interrelated) needs in terms of how they are categorized [McDonough et al. 2010, §18].

Moreover, digital editions are complex, layered objects. At base, they consist of one or more transcriptions or constructed texts, which may have been collated or further analyzed to produce altered texts. In most cases, these texts have been encoded using a markup language to identify features, define structure, and incorporate metadata; at the level of information, they are accompanied by products of scholarly analysis, such as a critical apparatus and various annotations. And in most cases, they are accessed through a software interface for reading, which may well be unique to the edition or project in question, and perhaps through APIs that provide data upon request. Even if the content of the edition began life encapsulated in a manageable format like a single XML file, the reading interface will encompass a multitude of files and technologies, like CSS and JavaScript files executed on a user’s computer and other processes, such as XSLT transformations, that may occur on a server entirely out of a user’s sight (so that the user may not even directly receive the underlying data files without requesting them). Any APIs the edition provides will operate similarly, extracting and transforming data to answer the requests it receives.

Given the complexity of digital editions as textual objects, one place we might turn for more robust ways to describe them as temporal, bibliographic objects is work done by electronic literature scholars in classifying and categorizing their materials. (Digital editions are indeed a form of electronic literature, albeit one that has not attracted much study outside the field of editorial theory.) Matthew Kirschenbaum in a 2002 article postulated a set of terms for describing first-generation electronic objects inspired by Bowers’s classic bibliographical typology [Kirschenbaum 2002]. Layer, version, and release refer to the whole software object — another hierarchy. Layer refers to a whole integrated environment of software and data; adding a brand new software interface, for example, might constitute a new layer. Version is somewhat subordinate to layer and describes the life sequence of the software; a new layer creates a new major version, while refining an existing layer creates a new minor version. Release seems to be primarily a matter of distribution channel: releases are “computationally compatible . . . but . . . not functionally integrated”, and Kirschenbaum’s example is of a work released both online and on CD-ROM (presumably with the same underlying software) [Kirschenbaum 2002, 48].

Within the total software object so described are individual objects — individual digital entities. Kirschenbaum offers a file as an example of an object, but it is worth noting that Kirschenbaum’s objects are independent of the data format in which they are stored. These are described by states: “the computational composition of an object in some particular data format.” For example, separate PNG and JPEG files representing the same image are different states of the same underlying object. Instance exists at the interplay between state and the software environment in which it operates: an image displayed in a particular program, which might (intentionally or inadvertently) render it differently from other programs. And finally, there is copy, a single instance of a state of an object, for example, the copy of an image that a web browser downloads and stores on a user’s computer (as distinct from the copy on the server).

I rehearse this categorization at length because it represents a particularly thorough and robust attempt to think through the distinctive properties of electronic objects, and it, too, points to some of the properties we must consider when evaluating digital editions. Kirschenbaum’s seven-part system is certainly too detailed and cumbersome to be used as a versioning system in itself — though a refined version, adapted for the era of networked publishing, might ultimately prove valuable when scholars of future decades write bibliographic accounts of digital editions. But his approach might suggest what sorts of features versioning needs to account for.

From the perspective of digital editions, the central insight of Kirschenbaum’s proposal is his distinction between the whole software environment and the individual components that compose it. An electronic text, consisting of both data and a technical environment in which that data is remediated for a reader, cannot usefully be described in total; media objects simultaneously precede their instantiation in a particular technical environment and become entangled in the systems that display them. Kirschenbaum applied this schema to works of electronic literature; those discussed in his account appear to have evolved in relatively well-defined, separable releases that can be thought of as an issue of all parts at once. His descriptive vocabulary seems to reflect this tendency: terms addressing the whole software environment are concerned with evolution, while those concerned with individual objects are concerned with instantiation.

This particular division would work well for describing digital editions of the CD-ROM era, where the production of physical copies created a distinct issue of the whole, including both data and display software. But versioning all the parts together appears less appropriate for the “continuous publishing” practices of the web era, where individual components (and most importantly individual documents) may be updated independently, not to mention the prevalence of digital editions in large archives containing many documents, and even in semi-distributed systems like Jeffrey Witt’s Scholastic Commentary and Text Archive (SCTA), which promises to aggregate related, interoperable editions [Witt n.d.] [Witt 2018]. If Peter Boot and Joris van Zundert are correct that distributed, networked systems combining many data sources and services are the future of digital editions (“the digital edition 2.0”, as they call it), versioning all the components of an edition as a single unit may well become completely impossible [Boot and Zundert 2011].

Accordingly, rather than versioning whole systems, we should offer separate treatment of objects and environments. Objects, here, are the edition content: the texts or other resources being presented online, as represented in the edition (not the physical objects being edited). Environment describes the whole system within which these objects are rendered and consumed: a web of server-side and client-side electronic processes that work in tandem with a user’s local computer environment to display an edition, or that provide data to other systems upon request.[25] Put another way: objects are the underlying data, the textual and editorial content that editors create and incorporate into the edition, regardless of the specifics (technical or visual) of its realization. Environment encompasses the interfaces through which that data is made available to users (the visual layout of an edition on the screen, APIs that permit machine-driven access to edition data), as well as the software environments that enable these forms of access.[26]

In arguing for the separation of object from interface, I do not mean to imply that interfaces are “mere” technical contributions, separate from the intellectual work of editing.[27] Nor am I suggesting that a reader or user of an edition can experience content in some pure way, uninflected by the way it is presented. The layout (interface) even of traditional print editions constitutes an argument about the material and its character [Eggert 2013]. The vaunted flexibility of digital editions means an edition may contain and present its material in multiple ways, indeed, through quite different interfaces, yet these interfaces will inescapably condition the material and make arguments about understanding it [Andrews and Zundert 2018]. Certainly, the form in which a text is encountered conditions understandings of that text, and citing the environment in which it is encountered will be necessary both to understanding conclusions drawn from the edition and to recognizing intellectual contributions to it.[28]

Despite the entanglement of content and presentation for scholarly understanding, versioning objects separately from their environments has both intellectual and practical benefits. One influential idea in software design, and key principle of the modern web, is the separation of form and content: the principle that documents should be encoded according to their underlying structural logic, without intermixing instructions regarding how that content is to be displayed.[29] The separation of form and content has understandably been drawn into question by scholars gesturing toward the outpouring of work on the materiality of text.[30] Nevertheless, this distinction operates at a technical level in many digital editions, and offers a model by which digital editions may be implemented and preserved. The TEI guidelines, perhaps the most common standard for textual encoding of digital editions (see Franzini et al. (2019), 16), endorse and support the separation of form and content.[31] C. M. Sperberg-McQueen has gone so far as to suggest that it is a best practice for digital editions to provide multiple interfaces, not just to support multiple ways of interacting with the text but also to force editors to make sure they are not basing their encoding on desired display rather than the logic of the content [Sperberg-McQueen 2009, 35–36]. While others might argue for tighter control over the presentation of an edition as an editorial responsibility,[32] the edition content and presentation are still technically and intellectually separable even when they are thought of as forming a single intellectual unit. Put another way: Sperberg-McQueen distinguishes among the infinite array of facts concerning a particular text, the selection of facts that are contained as information within a particular edition, and the presentation of those facts, for instance through arrangement on the screen. The selection of facts — the total information content available in an edition, whether exposed in a particular form or not — exists, as encoded data, apart from the mechanisms that present those facts, even where the selection of facts and the development of the user interface have informed each other and where they are intended to go together [Sperberg-McQueen 2009, 31].[33] Unless a creator goes to extreme lengths, against all norms of software design, to create a boutique piece of software in which data and display are fully entangled, it is likely that any digital edition (regardless of the standards or ad-hoc principles followed) will contain data objects that can be meaningfully versioned apart from their display systems.

Moreover, at a practical level, objects and environments are likely to evolve separately, both before and after an edition is published. An editor who learns of an error in a reading can correct it by making a change in a data file; in many online publishing environments, no further action will be required for the correction to appear in the edition.[34] Similarly, the developers and maintainers of digital editions can often make changes from tweaking the text styling to rearranging the graphical user interface to adding major new features for textual analysis without altering the data files. Versioning data objects can also aid preservation. Because the underlying data in most edition objects is at heart textual, data files can be relatively easily archived in repositories designed for storing texts, like the Oxford Text Archive [Oxford Text Archive n.d.] and TextGrid [TextGrid Consortium 2006-2014]. Depositing an edition’s data is not the same as preserving the edition, and work on the preservation of the interfaces should continue (informed by work in the field of software preservation), but such deposits can help allow the labor represented by an edition to live on as data even if its software becomes inaccessible.[35]

As publishing practices evolve, being able to refer to objects separate from their environments may increasingly become a practical necessity. Boot and van Zundert’s vision of a networked, distributed “digital edition 2.0” involves bringing data together with services offered by different providers, and they explicitly argue that editions should not provide their own “advanced services” [Boot and Zundert 2011, 144]. Users of digital editions may already be prepared to work with data apart from interfaces; in a recent survey about digital editions, a majority of respondents rated the ability to download and reuse data from editions “very important” [Franzini et al. 2019, 15]. Even without such a shared infrastructure, thinking separately about object and interface helps prepare us for the future agitated for by Peter Robinson, where digital editors abandon the practice of providing their own interfaces and leave textual display to others [Robinson 2013]. Increasingly, those working in the field of digital editing recognize the value of publication frameworks and software packages that allow editors to present their work without having to develop entirely new software.[36] Alternative environments need not be software systems; as discussed below, the Piers Plowman Electronic Archive has begun publishing printed volumes produced from its XML data, providing paper-based access to the edition. Versioning objects and environment separately means that our versioning practices can recognize the intellectual identity between an encoded document (for example, an XML file in the TEI vocabulary) and its rendering (for example, its rendering as an HTML page as a result of an XSLT transformation). They remain the same object, even if the mediating layers change.[37]

Although the remainder of this article focuses on versioning data objects, versioning software environments (including the web platforms that display digital editions) is also important for the future health of the digital scholarly ecosystem, and should be an area of further work for the field. A FORCE11 working group has emphasized the importance of scholars citing the software they use in their research, for reasons of credit, provenance, and reproducibility, and has indicated that one goal of software citation should be to identify and facilitate access to a specific version of the software [Smith et al. 2016]. Although the primary focus of software citation movements has been software executed locally by researchers, such principles might furnish a starting place for citation of web-based environments in which the contents of digital editions are accessed. Publishers of digital editions might facilitate such citations by assigning their online software platforms specific version numbers, incremented with every update, even when the web interface is specific to a single project. Researchers citing a digital edition might then cite both the data underlying the edition and the platform in which they accessed the edition. Publishers might also consider making the source code of online platforms available under open source licenses, potentially enabling future researchers to recreate an earlier version of an online platform that has since been updated or discontinued. Of course, such steps are at best partial. The ways in which a user experiences the data mediated by an online edition platform depend not merely on website code, but on underlying elements of the web architecture (such as the specific versions of software running on the web server) and on features of a user’s own computer, such as operating system, web browser, and specific settings. Research into the preservation and curation of software as a part of the scholarly record is ongoing, and as the field of digital editing and publication continues to mature, it will need to become involved in these broader conversations.[38]

But there is lower-hanging fruit for editors and publishers of scholarly editions, who have yet to develop standards for the comparatively straightforward versioning of edition contents, standards that would benefit the field of scholarly editing. Versioning the contents of digital editions would represent a significant step forward for citeability and preservation of the scholarly record even while difficult issues regarding software environments await future work. We can, and should, version the data objects that form the information content of our digital editions, starting now.

I will turn now to a case study based on my work in creating a formal versioning policy for the Piers Plowman Electronic Archive (PPEA) [Duggan et al. 2019], an open-access online resource that aims to document the complete medieval and early modern textual tradition of the Middle English alliterative poem Piers Plowman through TEI-encoded documentary editions of individual witnesses and critical editions of archetypal texts. This long-running project, which began in 1987, demonstrates both the need for and the challenge of clear versioning practices.[39]

The first seven PPEA editions were published on CD-ROM, from 2000 to 2011, in separate partnerships between the Society for Early English and Norse Electronic Texts (SEENET) and the University of Michigan Press, Boydell and Brewer, and the Medieval Academy of America. The first two CD-ROMs were encoded in SGML presented using the proprietary Multidoc Pro SGML browser; later editions were encoded in XML and published using software that ran within a web browser. In 2014, all texts were made openly available online, in a new web interface created by the Institute for Advanced Technology in the Humanities at the University of Virginia. The new online Archive saw the release of previously unpublished editions; older editions were updated to XML conforming to the P4 version of the TEI guidelines. Since 2014, intermittent changes have been made to the appearance and function of the web editions. Forthcoming updates will create additional versions of existing texts: the Archive is in the process of updating its texts to TEI P5, and the newly launched PPEA in Print series publishes print volumes derived from electronic texts.[40]

In addition to changes in medium, file format, and technical infrastructure, the PPEA, like any project of its age and scope, has had to deal with errors in its materials. The web versions of the texts were updated to correct known errors. These changes were not explicitly recognized on the pages for the text. For texts originally published on CD-ROM, the website used to provide Errata lists recording corrections to the CD-ROM texts. However, these lists are no longer maintained given the age of the CD-ROMs, and Errata lists were never created for texts first published online. The corrections made to files spanned a wide range of types and significances, including changes to the format of line numbers (but not the lineation), minor changes to markup unlikely to affect the output on the screen, and the correction of textual errors.

As part of a CLIR Postdoctoral Fellowship in Data Curation for Medieval Studies at the North Carolina State University Libraries, I set out to create standards for assigning version numbers to texts. My primary goals were (1) to allow users of the Archive to record and cite unambiguously which version of a text they consulted; (2) to permit previously published versions of texts to be archived and retrieved; (3) to make the history of a given text legible; and (4) to allow users with references to two versions of the same text to have a basic understanding of the relationship between them. From the start, I was concerned only with versioning published resources; while we might use prerelease identifiers to track the evolution of unpublished resources internally, what I sought to define was how we would assign version numbers to editions beginning at the moment of their publication and encompassing all successive published changes.[41]

A few fundamental decisions guided my work. One early, crucial question was what resource was actually being versioned. First, guided by Kirschenbaum’s work, I concluded that edition content and the way that content is displayed cannot be described by the same version numbers. While versioning our display software is a long-term desideratum, my immediate goal was to version editions’ informational content. Accordingly, any version numbers we provided would have to refer to the source files for an edition — in this case, the TEI-encoded XML — rather than to its rendered text. The decision to privilege the XML made sense as the XML files can be easily archived, and because it recognizes the markup of an edition as a significant intellectual product. Versioning the XML files also allows us to link them with any derivatives produced from them: derivatives which can include not just electronic renderings but print volumes.[42] For instance, editions published in the PPEA in Print series carry a statement on the copyright page declaring the version of the XML files to which the print text corresponds.

Choosing XML files as the objects of versioning has additional consequences. The component files of an edition will be versioned separately. Each full edition consists of, at minimum, separate XML files for the introduction and the edited text. If the versioned objects are XML files, a change to the text does not affect the status of the introduction. Even though the PPEA conceives of each edition as a single coherent publication, and they are peer reviewed as integral wholes, they are made up of separate data sources whose version histories must be managed independently. (This is a more practical approach than creating data packages versioned as a single unit because it allows us to include a file’s version number within the file itself without having to modify files that have not otherwise changed.)

One more question concerned what resources must actually be versioned. The PPEA website contains many pages with background information and supplementary resources that are not part of individual editions — some of which, such as site credits, may change frequently. Further, editions include files such as prefaces that are not necessarily advancing the same sort of scholarly claims. At least for the time being, I decided to version only content subject to peer review, meaning the text, apparatus, and introductions of editions.

Establishing some priority of changes that gives a sense of their scope is essential to make version numbers useful. Thus I sought to distinguish changes on the grounds of their scale and significance.[43] Changes that systematically affected the editorial or markup approaches to a file seemed to constitute a highest level of change. A file’s markup might change completely — it might, indeed, be recreated from the ground up in a new format (for instance in HTML rather than XML) — without any differences being visible to users of the edition. However, given the intellectual significance of the way a text is marked up, these two files would be radically different from each other as data. Accordingly, I reasoned, the conversion of a file from one markup language to another (from SGML to XML, or between major versions of an encoding scheme, like the transition from TEI P4 to P5) would constitute a major release (at the highest level of versioning), because even if the intent is to keep the textual content the same, the different affordances of different file formats and encoding schemes mean that the nature of the file has fundamentally changed.[44] A file modified in this way is incompatible with previous versions in a concrete sense, because changed elements and structure mean that the files can no longer be compared directly to each other by analytical tools that process the underlying XML, and software that worked with earlier versions may not display it successfully. (However, minor changes to how data is stored or expressed, like a switch between minor versions of TEI or a change in character encoding from ISO-8859-1 to UTF-8, maintain the fundamental identity of the file and do not rise to the level of a major release.) Similarly, systematic editorial revisions to a file, I suggested, would constitute a new major release, because they represent a far-reaching editorial reassessment that disrupts intellectual continuity with the existing version. In its relationship to preceding material, a major release is in some ways comparable to a new edition of a print book (marked by a new setting of type), or to a significant version in the text-critical sense.

Since one of the central goals of a digital edition is to present one or more texts, any changes to readings are necessarily significant. I therefore proposed that individual changes to the text that do not rise to the level of systematic revision might constitute a middle level, less high than systematic changes but greater than other forms of change. The concept of a “patch”, a change intended only to correct an error and restore expected behavior, does not apply to an edition, because edition contents may have been used as the grounds for scholarly argument and the change from a mistaken reading to a correct one may thus have great scholarly significance. If changes to text are regarded as the more significant form of local change, then changes to paratext, including editorial content, might be at the lowest level. These three levels of change seemed well suited to the common three-level version number format. I therefore initially proposed that version numbers take the following form: [systematic changes to encoding or editing].[changes to text].[changes to paratext]. I outlined the meanings of these segments as follows:

• The first segment, systematic changes, would increase when we make a large number of changes systematically across the text that have a significant effect on its markup or on the how it is edited as a whole.
• The second segment, changes to text, would increase when we make any change to our representation of what is on the page. Most obviously this includes alterations of readings, but it also includes highlighting and other features present in the source document.
• The third segment, changes to paratext, would increase when we make changes to paratextual content that is not in the source document, such as editorial notes and apparatus.

This proposal sparked discussion with other project leaders. One specific point of debate was the extent to which version numbers should reflect the file history. Following the conventions of software versioning (and of bibliographic classification), I proposed that when any segment of the version number changed, all segments to the right should revert to zero. (So, for instance, version 2.1.3 might be followed by 3.0.0.) Our discussion raised the possibility that this practice hid file history, as after a systematic change it would no longer be clear how many changes to text or paratext had occurred. An alternate proposal was that each segment would increment independently without being reset, so that the number of changes of each type would be permanently visible. That alternative proposal raised its own complications. For one, it deviates from the practices typical of software version numbering, and so would likely prove confusing to users: the practice of zeroing-out later segments is culturally familiar not just from annual demands that we upgrade our phone operating systems, but from its cultural currency in the form of phrases like “web 2.0”. In addition, it creates a false impression of precision, because any number of changes might be bundled into a single update to the file. (For instance, a single update might include three separate alterations to the text and two to the paratext, but the final two segments of the version number would each increase only by one, concealing the actual number of changes.) And there is in any case a hierarchical bibliographical logic to the major version’s resetting the clock on other forms of revision: if a major version compares to a new edition, such a significant change establishes a new baseline against which less significant changes can be measured going forward.

Perhaps the most troubling aspect of three-level version numbers from the perspective of the PPEA, however, was the realization that not all files that need to be versioned can have changes at three levels. Files consisting purely of editorial material, such as introductions, do not have distinct textual and paratextual content in the manner of edited texts, and so version numbers would have to express all changes to these files in either the text or paratext segment, with the other segment remaining permanently at zero (or omitted entirely). The idea of versioning different XML files according to different principles, or of having a version number segment that would always remain zero for some files, seemed too unwieldy. And, of course, for readers interacting with and citing primarily editors’ comments, it is not necessarily the case that changes to text will be the most significant changes.

Accordingly, despite the potential advantages offered by three-part version numbers, we ultimately elected to adopt a simpler, two-part system for version numbers, in the form of [major version].[minor version], where the segments have the following meanings:

• The first segment, major version, increases when we make a large number of changes systematically across the text that have a significant effect on its markup or on the how it is edited as a whole. Moving from P4 to P5 of the TEI protocols, which requires non-trivial changes in markup across the text, is an example of a change that would increase the number of the major version segment.[45] The significance of any program of changes must be assessed by the resource’s maintainers in terms of the needs of the community that will use the resource, as the Semantic Versioning debate suggests.
• The second segment, minor version, increases when we make any other change. These include corrections to readings, updates to notes or paratexts, modification of markup, or changes of any other kind as long as they do not rise to the systematic, significant status that would constitute a new major version.

Users in possession of an XML file should be able to determine the version from that file, so the policy stipulates that wherever possible, the version number should be recorded internally within the file to which it applies. In TEI documents, we record the version number using the @n attribute within the <edition> element in the <editionStmt> section of the header. We also recommend documenting the revision history of the file using <change> elements within the <revisionDesc> section of the header; the version number should be attached to each change newly introduced within a particular version using the @n attribute on the <change> entity. In this way, we can both identity particular states of files and construct a human-readable history of how the file developed. Where version numbers and change histories cannot practically be included in the file itself, we will store them in a supplementary text file to be archived and distributed with the data files.

The practices considered and developed by the PPEA offer a starting point for versioning digital projects, laying out standards for what needs to be versioned and how version numbers can make the status of files and their histories more intelligible. Other projects, with different needs, materials, data formats, and philosophies may need to develop different strategies in order to make their material comprehensible and usable. Development of standard practices would benefit the field of digital editing as a whole. And standards and mechanisms for versioning will have to continue to evolve alongside ongoing developments in the field of digital editing. The versioning protocol developed for the PPEA is based on a document-driven paradigm of the digital edition — that is, on a model in which key informational components of the edition are contained in individual XML files, to which version numbers can be attached. But this model is a notably simple one, even in the context of the TEI. XML documents need not be self-contained; an XML document can virtually include content drawn dynamically from other sources, a design pattern that Alan Liu terms “data pours” and finds characteristic of the modern web [Liu 2004, 59–63]. Each source file could be versioned individually, but the compound XML that is processed to render the edition may never before have existed as a coherent whole; such hybrid documents threaten a nearly endless proliferation of versions, not to mention challenging technical measures to expose the version number of each element. And more complicated paradigms may become increasingly common in sophisticated digital editions of the future. For instance, in editions developed according to the principles of “stand-off” markup, there may be a “source” document containing a core stream of textual data, designed to work in tandem with various kinds of markup stored outside that document [TEI Consortium 2019, §16.9].[46] Some editions may even avoid storing data in documents that map to a traditional file system, opting instead for databases or other complex storage structures.[47] Versioning practices will require ongoing consideration to keep pace with the shifting field. These are conversations the digital editing community needs to begin to have.

Until even an initial community consensus emerges, individual projects will have to develop their own approaches to versioning their data — approaches that will shift in tandem with their needs, infrastructures, material, and scale. Accordingly, instead of a set of rules, I conclude with three principles that can help to guide discussions about versions of texts:

1. Digital editions must version their underlying data and communicate those versions to users, independent of how that data is displayed. This is not the same as tracking file history in version control; nor is it the same as the bibliographical analysis scholars of future generations may want to perform. It is a declarative act in which digital editors make assertions about the state of their work. Where editorial projects offer reading interfaces or APIs, they should strongly consider versioning their software environments, due to the complicated technological interactions required to display a text. However, versioning the data itself is of paramount importance. Wherever possible, editions should provide direct access to their versioned data (for example, in the form of TEI-encoded XML files) so that users can examine the data directly, apart from its interface.
2. Versioning is social. As debates in the software community have suggested, versioning is not an abstract concept, but is inherently tied to use. Developing versioning principles will requires editorial projects to have a use-model of their resources, one that takes into account what kinds of changes are intellectually and practically significant. This means, for instance, deciding what types of object are fundamental to the resource and at what level they should be versioned. (A single epigraph, or a corpus? Chapter or novel? Poem or volume? The entire archive offered by a large project? Given both creators and users, how should we understand the resource as transforming?)
3. Digital editions must explicitly scope their revisions, delivering version numbers that communicate with users (based on their needs) the scale and significance of the change. It should be possible to understand through version numbers not only what version of a resource is most recent, but how “compatible” they are, how likely it is that the differences have a significant impact on their intellectual coherence or their probable uses. Both in individual projects and the field of digital editing as a whole, we should develop explicit guidelines that make these versions meaningful.

Kirschenbaum has claimed that despite the significant technical challenges of digital preservation, its greatest challenges are “ultimately — and profoundly — social” [Kirschenbaum 2008, 21]. The same, I would argue, is true of the issues surrounding the evolution and internal histories of digital editions. The field must begin to develop standards and practices for managing resource histories — standards and practices that ideally should not be limited to any one file format or encoding scheme, but can help organize data of many forms, for many purposes, now and in the future. And other practices will need to develop around those standards: for instance, support for versioning in emerging APIs for digital scholarly text. Version numbers, I argue, can help meet these needs, and it is time for digital editors to begin discussing and using them.

My thanks to Timothy Stinson for his feedback on this article, and to Matthew Kirschenbaum for his comments on an earlier version of this work. I am also grateful to my many generous interlocutors at the BH and DH conference where I first presented these ideas, and to anonymous reviewers at DHQ. This research was made possible by the support of a CLIR Postdoctoral Fellowship in Data Curation for Medieval Studies at the North Carolina State University Libraries. Another version of this article will be published as “Versioning and Digital Editions”, in Book History and Digital Humanities, Wacha, H. and Vareschi, M. (eds), Center for the History of Print and Digital Culture and University of Wisconsin Press, Madison, forthcoming.

To get an idea of existing versioning practices in existing digital editions, I examined versioning and revision-tracking practices in the thirty “interesting editions/projects” singled out for recommendation in Patrick Sahle’s online Catalogue of Digital Editions [Sahle 2019]. These resources, comprising projects with start dates ranging from 1995 to 2018 and covering multiple fields, languages, and kinds of material, offer a convenient sampling of available digital editorial work. I examined each resource and attempted to determine whether it provided version numbers and whether it kept granular revision histories. To attempt to learn a project’s practices, I examined its opening page, pages describing the project and its technical and editorial policies, credits pages, citation instructions, and a small sampling of pages displaying texts belonging to the edition. Where a project provided direct access to its underlying data files (typically in the form of TEI-encoded XML), I also examined a few of these files to see if version numbers or revision histories were represented in the data files. Because my examination of the data files of any individual project was limited and manual, it is possible that a project includes version information or revision history in a file I did not examine, or discusses these matters in a portion of the site I did not access; however, my examination suggests broadly whether such information is accessible to site users. My findings are summarized in the table below, followed by brief discussion.

Of the projects represented, 18 (60%) acknowledge in some form that their resources may change over time. The most common form of acknowledging changes, practiced by thirteen projects (43%), is maintain a change log, which typically records a description of changes, the date on which they were made, and who made them. Four projects provide a list of changes as part of the website (in the case of the Vercelli, I suspect generated from the underlying data files, which are not accessible). These vary in detail; Schnitzler focuses on the addition of new content and features; Old Bailey discusses corrections but often summarizes changes made to many records simultaneously; the Whitman Archive provides a detailed description of revisions in an external blog. Ten projects, all encoded in TEI XML or a derivative format, store revision lists in each data file using the <revisionDesc> element; the Whitman Archive is noteworthy in providing both internal and external change logs.

Supplying version numbers is a rarer approach. Seven projects (23%) employ version numbers in some capacity. This total is split almost evenly between projects that assign a single version number to a given state of the project (3; 10% of the total) and those that version separate texts or data files independently (4; 13% of the total). Surprisingly, only three projects combine version numbers with a detailed listing of changes; in all cases one version number applies to the resources as a whole, though one of the projects records changes to individual files while the other two announce sitewide changes (including new features) in tandem with new versions.

The three projects using sitewide version numbers all use conventional two-segment version numbers.[59] Schnitzler is the only project to explicitly explain the meaning of its version numbers, the two segments of which correspond to major and minor releases: major releases are marked by the release of significant new functionality or materials, as anticipated by the phases mapped out by the Release Plan, while minor versions correspond to minor updates [Informationen zum Beta-release 2.0 2019].[60] Generally, these project-wide version numbers assign clear version numbers that clearly communicate something about the scope of their changes.

By contrast, the projects that grant version numbers to individual documents or data files use a much wider array of formats. Of the four projects that version individual resources, two conceive of versioning by analogy to print. The Rossetti Archive, on the pages for individual works within the archive, refers not to versions of its materials but to editions. At the bottom of the page for each item in the archive, the site gives an “Electronic Archive Edition” number as an integer; an item might be listed as edition 1 or 2.[61] Inspecting the XML files reveals that the book analogy is suggested in part by the TEI; the edition number is given in the document header using the <edition> element.[62] (Lord Byron similarly attaches an integer edition number to the <edition> element, though it uses the @n attribute, where Rossetti makes the edition number the element’s content; Lord Byron does not display this number in the reading interface.) These numbers provide a mechanism for recording changes, but the number’s low resolution combined with the ambiguity of the <edition> element and the lack of a stated versioning policy means that it is difficult to be certain the edition number will be updated with any change.

Petrus Plaoul, as available in the Scholastic Commentaries and Texts Archive, also refers to a state of one of its digital texts as an edition, but the identifiers it assigns suggests a more robust way of thinking about textual state. The identifier for an “edition” might take the form “2011.10-dev-master”, accompanied by the date “October 04, 2011”; these appear at the head of every text on the site (for example, Plaoul, 2011). These identifiers offer a form of Calendar Versioning, labeling a state of the text according to when it last changed, combined with what appears to be technical control information. The dot separation between the year and month visually evokes standard formats for version numbers. But of the projects profiled, only Codex Sinaiticus explicitly refers to states of its material as versions. The website detaches this information from the presentation of the text; I found the version number listed only on the XML Download page, where it is also accompanied by a revision date [XML Download n.d.]. The version number — 1.04 at the time of writing — is stored in the downloadable XML file, attached to the @n attribute of the <edition> element and also labeled “Version 1.04” in the content of that element, where it is accompanied by a date of last update (March 25, 2014). The <revisionDesc> element enumerates changes made to the XML file and parenthetically links each to the version number of the file in which the change was made. Of the projects examined, Codex Sinaiticus alone offers detailed version numbers capable of registering the scope of revisions, and it is also alone in explicitly articulating the link between labeled version and the revision history.

The field of digital editing as a whole shows an understanding of the importance of acknowledging resource change; a majority of the editorial projects surveyed take some steps to show how the current state of the resources differs from earlier forms in which the same resource was available. Based on the prevalence of various approaches to change, it appears that at least a partial consensus has formed within the field about using change logs to describe to human readers the changes that have occurred. By comparison, labeling specific states of the resource through the use of version numbers or other identifiers is much less common, and even among projects that do explicitly version resources, practices are wildly inconsistent. Should whole websites be versioned, or individual texts? What constitutes a version? What form should version numbers take? This article has argued that version numbers are necessary for data management and interoperability among digital editions. The significant disparities in existing practices highlight the need for a field-wide conversation to develop practices around versioning practices.