[FEATURE] Determine the version to publish from the extension - #104
Conversation
The version argument of `ter:publish` is optional now. If it is not given, the version is taken from the extension itself, in this order: 1. The tag of the checked out commit, with an optional `v` prefix. Tags which are no version, e.g. `latest`, are ignored. 2. The version in `ext_emconf.php`. 3. The version in `composer.json`, either on root level or at `[extra][typo3/cms][version]`. The last two are the ones maintained by the `set-version` command, so a release does not have to repeat its version on the command line. Tailor states which version it uses and where it comes from. If the checked out commit is tagged with more than one version, the version has to be given as argument. Since an extension key never looks like a version, `ter:publish my_extension` still works. The extension key is now read from the `composer.json` of the given `--path` as well, instead of always from the current working directory.
| if (count($versions) > 1) { | ||
| throw new VersionMissingException( | ||
| sprintf( | ||
| 'The checked out commit is tagged with more than one version (%s). Please state the version to use as argument.', | ||
| implode(', ', $versions) | ||
| ), | ||
| 1786492801 | ||
| ); | ||
| } |
There was a problem hiding this comment.
I'm unsure if we should really fail here if more than one version tag points to HEAD (which is actually a quite uncommon circumstance), since we probably still read it from composer.json or ext_emconf.php.
| $version = (new EmConfReader($path))->getVersion(); | ||
| if ($versionValidator->isValid($version)) { | ||
| return new ResolvedVersion($version, ResolvedVersion::SOURCE_EMCONF); | ||
| } | ||
|
|
||
| $version = (new ComposerReader($path))->getVersion(); | ||
| if ($versionValidator->isValid($version)) { | ||
| return new ResolvedVersion($version, ResolvedVersion::SOURCE_COMPOSER); | ||
| } |
There was a problem hiding this comment.
I'd give composer.json a higher priority than ext_emconf.php, since this reflects the new source of truth.
| $versions = []; | ||
|
|
||
| foreach ($this->getTagsOfHead($path) as $tag) { | ||
| $version = (string)preg_replace('/^v/i', '', $tag); |
There was a problem hiding this comment.
| $version = (string)preg_replace('/^v/i', '', $tag); | |
| $version = ltrim($tag, 'v'); |
not sure about this, regarding best practices. IIRR it is not adviced to pin the version in composer.json in a repo - it will always drift. Best practice is to leave version info in IMO the correct process for uploading packages, where needed:
IMO we need to better distinguish between composer/packagist/git deployment/release and the "old" TER way of publishing packages But i must admit I am not that deep in all this release processes, especially with TER |
|
I would go even further, running tailor in a repo should hard fail on invalid/missing version tagging. |
3 participants
The
versionargument ofter:publishis optional now. If it is not given, the version is taken from the extension itself, in this order:vprefix. Tags which are no version, e.g.latest, are ignored.ext_emconf.php.composer.json, either on root level or at[extra][typo3/cms][version].The last two are the ones maintained by the
set-versioncommand, so a release does not have to repeat its version on the command line:tailor set-version 1.5.0 git commit -am "[RELEASE] A new version was published" git tag -a 1.5.0 tailor ter:publishTailor states which version it uses and where it comes from:
Notes:
ter:publish my_extensionstill works - the sole argument is moved to the extension key.composer.jsonversion can never rescue a publish, since packaging validates thatext_emconf.phpcarries the same version. It does improve the error message though.composer.jsonof the given--pathas well, instead of always from the current working directory.The git repository is queried with
git -C <path> tag --points-at HEAD. A missing git binary, a disabledexec()or a path which is no repository simply means there is no tag to work with.