Score Release Numbering Scheme

We will use 4 numbering fields to number the releases. The first three are separated by a dot and the last field is separated an under bar.

• The first number indicates significant improvements or changes that may contain backward incompatibility changes (i.e., some data may be loss) to the application logic and/or database schema. The term 'significant' is fuzzy. The release may indeed contain no database change. When the first number increases we'll always provide a new database docker image, a new application docker image, and a data migration script. Data migration script may be an import/export procedure or database script or both.

• The second number indicates changes that involve database updates within the first number. When this second number increases, we'll always provide a new database docker image, a new application docker image, and a data migration script.

• The third number indicates changes only to the application within the first and second number combination. When this third number increases, only a new application docker image is provided. If this last number is not present, assume 0. No database image and data migration script will be provided.

• The fourth number indicates a patch/quick-fix release. The intention of patch release is only to prevent disruption to the development of the next dot release when there is a high-priority bug. In other words, we will only create patch releases against the latest dot release (while we are working on the next release). For example, if the next release that we are working on is 1.2.3, the previous release 1.2.2, we will only create patches against 1.2.2. There may or may not be database change occurring with the patch release and if there is, the release will be suffixed with 'd' and a data migration script will be provided.

Example.

• Release 1.0.0 => the first release. Database image with tag 1.0.0 and application docker image with tag 1.0.0 are available.
• Release 1.0.1 => minor bug fixes, enhancements to the first release. No database upgrade. Application docker image with tag 1.0.1 will be available. It is supposed to use the database image with tag 1.0.0.
• Release 1.1.0 => There are some changes that requires changes to the database. Database docker image and application docker image with tag 1.1.0 will be available. A data migration script from 1.0.0 to 1.1.0 will be available.
• Release 1.1.1 => minor bug fixes, enhancements to the 1.1.0 release. No database upgrade. Application docker image with tag 1.1.1 will be available. It is supposed to use the database image with tag 1.1.0.
• Release 1.1.1.1 => There is an an urgent bug fix needed in 1.1.1 while developing 1.2.0. In this example, there is no change to the database; therefore, only the docker application image is provided. It uses the database image with tag 1.1.0.
• Release 1.2.0 => There are some changes that requires changes to the database. Database docker image and application docker image with tag 1.2.0 will be available. A data migration script from 1.1.0 to 1.2.0 will be available.
• Release 1.2.0.1d => There is an an urgent bug fix needed in 1.2.0 while developing 2.0.0. In this example, suppose there is a change to the database therefore the docker application and database images with the 1.2.0.1d tag will be provided along with a data migration script. Hopefully, we don't have a lot of this.
• Release 1.2.0.2 => There is an an urgent bug fix needed in 1.2.0.1d while developing 2.0.0. In this example, suppose there is no change to the database therefore only the docker application with the 1.2.0.2 tag will be provided. Hopefully, we don't have a lot of this.
• Release 2.0.0 => There are some changes determined to be significant improvements. Database docker image and application docker image with tag 2.0.0 will be available. A data migration script from 1.2.0.1d to 2.0.0 will be available.