[dev] versions, .horde.yml and correct tagging

[Ralf Lang]

Hello,

on the weekend I worked a bit on the composer release toolchain in my
version of horde-components.
Good news is I think it works ;)

Bad news is I am a little unsure about versioning.

What I found out:

Current release branch FRAMEWORK_5_2 has:

.horde.yml

release: 5.2.24

api: 5.2.0

state:

release: stable

api: stable
version:

Application.php has

public $version = '6.0.0-git';


current master branch has:

.horde.yml

release: 6.0.0

api: 6.0.0

state:

release: beta

api: beta
version:

Application.php has

public $version = '6.0.0-git';

public $version = '5.2.24';

The latest tagged version is: 5.2.23


Similar pattern for imp:
Version master is 7.0.0, version Framework_5_2 is 6.2.28, latest tagged version is 6.2.27

So I understand: New major revision of the framework = new major revision of all libraries/apps, regardless of actual feature progress or bc break.

The complicated part comes with alpha/beta/rc releases as I did not yet find good examples of .horde.yml for these.

If I build a testing FRAMEWORK_6_0 branch and release, it would look like this:

In the first iteration, FRAMEWORK_6_0 would be a clone from master, plus two release related commits

The first tagged version would be "version 6.0.0" and the tag would be 6.0.0beta1, the $version string in the app would be 6.0.0beta1
The version on the branch would be "version 6.0.0" (as we would still be in beta counting), the $version string would be 6.0.0beta2 as a next tag would be 6.0.0beta2.

As soon as releases hit stable, the tip of branch would always be one patch level ahead of the latest tag.


-- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang at b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537