BlackBox Versioning Strategy - Revision history

Josef templ at 22:24, 28 October 2017

2017-10-28T22:24:33Z

← Older revision		Revision as of 22:24, 28 October 2017
Line 28:		Line 28:
	'''rc''' - release candidate		'''rc''' - release candidate

	'''no DevelopmentStage''' - means final release, in ~~his~~ case there is no build number in the file name.		'''no DevelopmentStage''' - means final release, in this case there is no build number in the file name.

	The stage numbers always start at 1 and are only incremented in case of stepping back to a		The stage numbers always start at 1 and are only incremented in case of stepping back to a

Josef templ at 08:28, 18 September 2014

2014-09-18T08:28:55Z

← Older revision		Revision as of 08:28, 18 September 2014
Line 3:		Line 3:
	The downloadable BlackBox packages carry a version information in their file names.		The downloadable BlackBox packages carry a version information in their file names.
	The same naming convention applies for installable setup.exe files as well as for		The same naming convention applies for installable setup.exe files as well as for
	zipped packages that can be installed by ~~deflating~~ the .zip file.		zipped packages that can be installed by unpacking the .zip file.
	Also the build-log file uses the same naming convention, which is defined below using		Also the build-log file uses the same naming convention, which is defined below using
	an EBNF grammar.		an EBNF grammar.

Josef templ at 11:34, 21 August 2014

2014-08-21T11:34:38Z

← Older revision		Revision as of 11:34, 21 August 2014
Line 1:		Line 1:
	The versioning strategy for the BlackBox ~~community edition~~ is as follows:		The versioning strategy for BlackBox distributions built by the BlackBox Framework Center is as follows:

	The downloadable BlackBox packages carry a version information in their file names.		The downloadable BlackBox packages carry a version information in their file names.

Josef templ at 11:26, 18 August 2014

2014-08-18T11:26:42Z

← Older revision		Revision as of 11:26, 18 August 2014
Line 14:		Line 14:

	AppVersion is maintained in a file named 'AppVersion.txt', which can be found		AppVersion is maintained in a file named 'AppVersion.txt', which can be found
	in the directory '~~System/Rsrc~~'.		in the directory 'appbuild'. The existence of this file in a branch signals that
			automatic building of that branch is enabled.
	By looking at the change history of this file the timeline of the development		By looking at the change history of this file the timeline of the development
	stages can be retrieved easily.		stages can be retrieved easily.
	Examples for AppVersion are: 1.7-a1, 1.7.3-b2, 1.7-rc1, 1.7		Examples for AppVersion are: 1.7-a1, 1.7.3-b2, 1.7-rc1, 1.7

	The stage letters have the following meaning:		The development stage letters have the following meaning:

	'''a''' - alpha: not feature complete, internal testing		'''a''' - alpha: not feature complete, internal testing

Josef templ at 07:01, 11 August 2014

2014-08-11T07:01:09Z

← Older revision		Revision as of 07:01, 11 August 2014
Line 32:		Line 32:
	previous development stage. The order of development stages is a then b then rc then final.		previous development stage. The order of development stages is a then b then rc then final.
	Thus, when for example '1.7-b1' turns out to have missing features or other severe problems,		Thus, when for example '1.7-b1' turns out to have missing features or other severe problems,
	development is set back to '1.7-a2', later followed by '1.7-b2' and '1.7-~~rc-1~~', etc.		development is set back to '1.7-a2', later followed by '1.7-b2' and '1.7-rc1', etc.

	The build machine maintains a sequential build number for every build performed.		The build machine maintains a sequential build number for every build performed.

Josef templ: Created page with "The versioning strategy for the BlackBox community edition is as follows: The downloadable BlackBox packages carry a version information in their file names. The same naming ..."

2014-08-11T06:58:37Z

Created page with "The versioning strategy for the BlackBox community edition is as follows: The downloadable BlackBox packages carry a version information in their file names. The same naming ..."

New page

The versioning strategy for the BlackBox community edition is as follows:

The downloadable BlackBox packages carry a version information in their file names.
The same naming convention applies for installable setup.exe files as well as for
zipped packages that can be installed by deflating the .zip file.
Also the build-log file uses the same naming convention, which is defined below using
an EBNF grammar.

FileName = "blackbox-" AppVersion ["." BuildNumber] + ("-setup.exe" | ".zip" | "-buildlog.html").

AppVersion = MajorVersion "." MinorVersion ["." PatchLevel] [DevelopmentStage].

DevelopmentStage = "-" ("a" | "b" | "rc") StageNumber.

AppVersion is maintained in a file named 'AppVersion.txt', which can be found
in the directory 'System/Rsrc'.
By looking at the change history of this file the timeline of the development
stages can be retrieved easily.
Examples for AppVersion are: 1.7-a1, 1.7.3-b2, 1.7-rc1, 1.7

The stage letters have the following meaning:

'''a''' - alpha: not feature complete, internal testing

'''b''' - beta: feature complete, ready for external testing

'''rc''' - release candidate

'''no DevelopmentStage''' - means final release, in his case there is no build number in the file name.

The stage numbers always start at 1 and are only incremented in case of stepping back to a
previous development stage. The order of development stages is a then b then rc then final.
Thus, when for example '1.7-b1' turns out to have missing features or other severe problems,
development is set back to '1.7-a2', later followed by '1.7-b2' and '1.7-rc-1', etc.

The build machine maintains a sequential build number for every build performed.
This information is not under Git version control but local to the build machine.

The generated BlackBox.exe file also carries version information.
See 'Properties' of this file under the Windows Explorer.
The version information here consists of four version numbers:
MajorVersion.MinorVersion.PatchLevel.BuildNumber, where PatchLevel defaults to 0 if missing in AppVersion.

The build machine derives all required version information from 'AppVersion.txt' and from the
internally maintained build number. There is only one single place in the source code
repository that needs to be changed in order to express a switch from one development stage to another.