How versioning works in lists and libraries

Usually, a major version represents a milestone, such as a file submitted for review or publication, whereas a minor version is a work in progress that isn't ready for all site participants to read. Depending on the way your team works, your team may be more likely to need its most recent minor versions, such as a version that was edited recently. Over time, your team may be less likely to need an older minor version.

Some organizations track both major and minor versions of files in their libraries. Others only track the major versions. Major versions are identified by whole numbers, such as 5.0; minor versions are identified by decimal numbers, such as 5.1.

Most organizations use minor versions when files are under development, and major versions when certain milestones are reached or when the files are ready for review by a wide audience. In many organizations, draft security is set to allow only the owner of a file and people who have permissions to approve files. That means that minor versions cannot be seen by anyone else until a major version is published.

Major versions are available for lists, but minor versions are not available. Each version of a list item is numbered with a whole number. If your organization requires approval of items in a list, the items remain in Pending status until they are approved by someone who has permissions to approve them. While in Pending status they are numbered with decimal numbers and are referred to as drafts.

For more on enabling and setting up versioning, including major and minor versions, see Enable and configure versioning for a list or library.

Version numbers are automatically added each time you create a new version. In a list or library that has major versioning enabled, the versions have whole numbers, such as 1.0, 2.0, 3.0, and so on. In libraries, your administrator might enable versioning for both major and minor versions. When minor versions are being tracked, they have decimal numbers such as 1.1, 1.2, 1.3, and so on. When one of those versions is published as a major version, its number becomes 2.0. Subsequent minor versions are numbered 2.1, 2.2, 2.3, and so on.

When you discard a checkout, the version number does not change. If the most recent version was version 3.0, it remains at 3.0 after you discard the checkout.

When you delete a version, the version goes to the Recycle Bin and its number goes with it. The Version History will show the remaining version numbers. The other version numbers do not change. For example, if you have a document that has minor versions 4.1 and 4.2, and you decide to delete version 4.1, the resulting version history shows only versions 4.0 and 4.2. The following picture shows this.

For more on enabling and setting up versioning, including major and minor versions, see Enable and configure versioning for a list or library.

You can configure who can view drafts of list items and files. Drafts are created in two situations:

• When a minor version of a file is created or updated in a library that tracks major and minor versions.

• When a list item or file is created or updated but not yet approved in a list or library in which content approval is required.

When you track major and minor versions, you can specify whether people must have permission to edit files before they can view and read a minor version. When this setting is applied, people who have permission to edit the file can work on the file, but those who have permission only to read the file cannot see the minor version. For example, you may not want everyone who has access to your library to see comments or revisions while a file is being edited. If major and minor versions are being tracked and no one has published a major version yet, the file is not visible for people who do not have permission to see draft items.

When content approval is required, you can specify if files that are pending approval can be viewed by people with permission to read, people with permission to edit, or only the author and people with permission to approve items. If both major and minor versions are being tracked, the author must publish a major version before the file can be submitted for approval. When content approval is required, people who have permission to read content but do not have permission to see draft items will see the last approved or major version of the file.

Regardless of whether people have permission to edit a file or not, if people search for a file that is in minor version, they won’t get results for it.

Some organizations allow unlimited versions of files and others apply limitations. You might discover, after checking in the latest version of a file, that an old version is missing. If your most recent version is 101.0 and you notice that there is no longer a version 1.0, it means that the administrator configured the library to allow only 100 major versions of a file. The addition of the 101st version causes the first version to be deleted. Only versions 2.0 through 101.0 remain. Similarly, if a 102nd version is added, only versions 3.0 through 102.0 remain.

The administrator may also decide to limit the number of minor versions to just those for a set number of the most recent versions. For example, if 100 major versions are allowed, the administrator might decide to retain minor drafts for only the most recent five major versions. The default number of minor versions between major versions is 511. If you attempt to save another minor version, you will see an error message that tells you that you must first publish the document.

In a library that limits the number of major versions that it keeps minor versions for, the minor versions are deleted for the previous major versions when the version limit is reached. For example, if you keep drafts for only 100 major versions, and your team creates 105 major versions, only the major versions will be kept for the earliest versions. The minor versions that are associated with the five earliest major versions — such as 1.2 or 2.3 — are deleted, but the major versions — 1, 2, and so on — are kept, unless your library also limits major versions.

Limiting the number of versions is generally a good practice. It means you can conserve space on the server and reduce clutter for users. But, if your organization is required to save all versions for legal or other reasons, don’t apply any limits.

For more on enabling and setting up versioning, including major and minor versions, see Enable and configure versioning for a list or library.

When you check out a file from a library that has versioning turned on, a new version is created every time you check it back in. And, if major and minor versions are turned on, you can decide, at check-in, which type of version you are checking in. In libraries where checkout is required, versions are only created upon check-in.

In libraries where checkout is not required, a new version is created the first time you save after opening the file. Each subsequent save overwrites the version that you created with the first save. If you close the application and then reopen the document, the first save will, once again, produce a version. This can cause the number of versions to proliferate very rapidly.

For more info on check in and out, see Check out, check in, or discard changes to files in a library.