29 Mar 2020
This is a companion discussion topic for the original entry at https://typo3.org/article/typo3-core-9-5-15-and-8-7-32-maintenance-releases-published
This is a companion discussion topic for the original entry at https://typo3.org/article/typo3-core-9-5-15-and-8-7-32-maintenance-releases-published
After composer update I am on the dev branch. I don’t think, this should happen. Have I done anything wrong?
Hello!
I have the same problem but in the TYPO3 CMS 9 5 14
The tag v9.5.15, clearly shows that the constant TYPO3_version was updated from ‘9.5.15-dev’ to ‘9.5.15’. And yet when installing that version via composer, this is not what we receive as demonstrated in an empty folder:
/tmp$ mkdir test
/tmp$ cd test/
/tmp/test$ composer require "typo3/cms-core:^9.5"
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 44 installs, 0 updates, 0 removals
[ REDACTED FOR LENGTH ]
- Installing typo3/cms-core (v9.5.15): Loading from cache
[ REDACTED FOR LENGTH ]
/tmp/test$ grep TYPO3_version public/typo3/sysext/core/Classes/Core/SystemEnvironmentBuilder.php
if (defined('TYPO3_version')) {
define('TYPO3_version', '9.5.15-dev');
This seems to indicate that the package delivered via composer is not the same as the repository. Was the release process somehow buggy ?
Digging further, we can see that the v9.5.15 tag in the subtree is not the same commit as the v9.5.15 tag in the original repository. The subtree tag should read “[RELEASE] Release of TYPO3 9.5.15”, but instead read “[TASK] Allow composer installers 3.0 and higher”.
Coming back to the original repository we can find out that it means that v9.5.15 delivered via composer is lacking 4 commits. Specifically “[BUGFIX] Revert: Make default folder structure aware of ‘web-dir’ option” and the release commit might be a problem for some installations.
I’d recommend to release a 9.5.16 as soon as possible.
1 Like
Further upgrade instructions
No database upgrades are required for these maintenance releases.
This information is not correct.
After update core from 9.5.14 to 9.5.15 needs to make Analyze Database Structure because in core 9.5.15 has changed .sql
ALTER TABLE `sys_file_processedfile` CHANGE `configuration` `configuration` BLOB DEFAULT NULL
Current value: configuration TEXT CHARACTER SET utf8 DEFAULT NULL COLLATE `utf8_unicode_ci`EDIT: Please do not use the my described method. Use the downgrade method described in the article.
The tag was changed without notifying us. So: remove the core extension, clear the composer cache, remove the lock file and do a composer install. Now you should have the correct version.
This is bad practice and should be prevented by using annotated tags instead of lightweight tags. Otherwise anybody can “re-release” any previous version with any new content at any point in time. Breaking a lot of assumptions for end-users (composer.lock cannot guarantee consistent result anymore), and opening security holes in case of bad actor gaining access to repository.
With the following command, we can see that the original repository correctly use annotated tags (referred as tag), but the subtree repository is using lightweight tags (referred as commit).
/t3core$ git remote get-url origin
git://git.typo3.org/Packages/TYPO3.CMS.git
/t3core$ git show v9.5.15 | head -1
tag v9.5.15
/tmp/core$ git remote get-url origin
https://github.com/TYPO3-CMS/core.git
/tmp/core$ git show v9.5.15 | head -1
commit 1b955cdd084daf2596162c27d543891d6271b381
Who/where does this bug should be reported to ?
edit:
Removing the lock file, means all packages will be updated. This should be fine if you declare your dependencies correctly in composer.json and all your dependencies strictly conforms to semver. But even then, it can also introduce legitimate bugs.
This should have been avoided by cleanly releasing a brand new v9.5.16, instead of overwriting an existing release.
1 Like
Thank you for letting us know. Database upgrade are indeed required.
@benni could you please edit the news to reflect that ?
This can quickly be seen via the following command:
/t3core$ git diff v9.5.14 v9.5.15 '*.sql'
diff --git typo3/sysext/core/ext_tables.sql typo3/sysext/core/ext_tables.sql
index d0fe5a6391..d8a12ed09d 100644
--- typo3/sysext/core/ext_tables.sql
+++ typo3/sysext/core/ext_tables.sql
@@ -246,7 +246,7 @@ CREATE TABLE sys_file_processedfile (
original int(11) DEFAULT '0' NOT NULL,
identifier varchar(512) DEFAULT '' NOT NULL,
name tinytext,
- configuration text,
+ configuration blob,
configurationsha1 char(40) DEFAULT '' NOT NULL,
originalfilesha1 char(40) DEFAULT '' NOT NULL,
task_type varchar(200) DEFAULT '' NOT NULL,
Hey everybody.
Thanks for your replies. The database tables is not required - that is the main point. It solves an edge-side issue on PostgreSQL and having nullable processed file crop areas. This is solved, but this worked for 99.9% of the users before and after. So doing this change is not required at all.
In general it probably might make sense to add another comment. “There are database changes, but only needed in certain circumstances”.
1 Like
The tagging system for the subtree split did not work out during the release. This tagging script is responsible for adding tags to certain subrepositories for the “composer-mode” packages. This tagging script is maintained by TYPO3 GmbH - so I did not know what to do. The solution was only found 24hs later, where existing tags were force-pushed again. I will update the news accordingly.
2 Likes
Thank you for taking the time to amend the news. Recommending a composer downgrade to 9.5.14 is a good idea.
Thanks for the hint. You are right, my method of getting the new tagged commit was risky. We had the right setup for it. But of course: that can’t be guaranteed.