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

[Ralf Lang]

Am 23.02.21 um 14:30 schrieb Ralf Lang:
> Am 23.02.21 um 14:00 schrieb 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.
> Currently NextVersion only minds the verbatim version from .horde.yml
>
> So if the .horde.yml file says 6.0.0 and beta, it produces:
>
> tag: v6.0.0
> Entry in .changelog.yml: 6.0.0
>
> I think the .horde.yml version string should be the full tag including
> alpha, beta or rc version. This should also be the key for
> .changelog.yml. With these changes, everything works as i think it is
> intended.

I've gone ahead and generated a FRAMEWORK_6_0 branch and
(next).0.0alpha1 packages for more or less everything.
https://horde-satis.maintaina.com

I also converted .horde.yml pear requirements to composer requirements
unless where packages are missing on packagist. These are mostly
optional dependencies.

Only those packages which require it have received an autoloader hint -
mostly those which break PSR-0 rules (core, and some others) or have
namespaced code. For all others, autoloader looks for PEAR PSR-0 style
hierarchy in /lib and PSR-4 style namespaced classes in /src (if exists)

While generating composer.json from .horde.yml is well-automated, the
semi-automated upgrade of .horde.yml is a little hacky. It's been a long
evening after a long work day.



-- 

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