Skip to content

PS5 – Porting Knowledge: Versioning

You are here:
Estimated reading time: 2 min

by Luiz Aguilar and Rodrigo Martins

Versioning

In the world of group development, there are numerous critical issues that can bring a team’s production rate to almost zero. Some of these issues include communication, dependency, and control.

Communication refers to always knowing what the team is working on and what is happening in the project. Dependency arises when individuals rely on each other’s work to get their own tasks done. Control involves the ability to decide and manage what is being implemented in the project, the state and integrity of the project, and the accessibility of the version you are working with.

Version control is the means by which you can keep track of all these aspects. This way, any developer, from any field of expertise, can check, based on version numbers and release notes, what is implemented in the version they are working on, what is missing, and at what stage of the release cycle that version is in.

Basic Version Numbering

Every project version should have its basic version number, so that each time you modify the project and are ready to submit your changes, it’s considered a new version. This version number is based on four numbers separated by dots, X.Y.W.Z, which should ALWAYS be incremented with each modification.

X

 This number is the MAJOR version; it is incremented when you make incompatible API changes, typically used for releases. Example: “1.0.0.0 -First release without modifications” (Usually the initial submissions for certification are delivered with builds containing this numbering).

Y

 This number is the MINOR version; it is incremented when you add functionality in a backward-compatible manner, typically used for content updates or (DLC). Example: “1.1.0.0 -The first version with some new features or content updates.”

W

 This number is the development stage identifier of the version. Example: “1.1.1.0”

Z

 This number is the PATCH version; it is incremented when you make backward-compatible bug fixes, essentially bug patches. Example: “1.1.1.5 -First major version with various bug patches.”

Internal Development Number

The internal development number is a series of x.y.z added to the basic version number with a hyphen, where x.y.z represent the MAJOR.MINOR.PATCH versions.

 Differing from the basic version number due to its purpose, this number is used for pre-release modification versions to assist in production changes. Since alpha, beta, release candidate, and release are all forms of release, this number is used to track the modifications/commits made to achieve a basic version:

  • 1.2.0.3-0.5.2: A version with one major version, 2 DLCs, and 3 secondary patch versions released to fix bugs. After that, in production, we have 0 incompatibilities, 5 feature modifications, and 2 bug patches.
  • When the team finishes updating the internal dev number, they will likely increment the version to 1.3.0.0 and remove the “-0.5.2” from the version number.

Versioning Final Summary

1.2.0.4: MAJOR.MINOR.STAGE.PATCH

 Primarily concerning versioning for store submissions, we can assume that error-free versioning follows this pattern:

  • Master Version 01.00 Content ID Version 01.00
  • Master Version 01.00 Content ID Version 01.01 (patch 1)
  • Master Version 01.00 Content ID Version 01.02 (patch 2)

 If there is an issue with the game submission and it requires fixing an error in the package, then it would proceed as follows:

  • Master Version 01.00  Content ID Version 01.00 (Submitted with error)
  • Master Version 01.01  Content ID Version 01.00 (Everything went well)
  • Master Version 01.00  Content ID Version 01.01 (Error-free version) (patch 1)

 

Attachments

Was this article helpful?
Dislike 0
Views: 10
Back To Top