mirror of
https://github.com/FriendsOfTYPO3/tea.git
synced 2024-11-24 08:56:12 +01:00
Merge branch 'main' into TASK/use-development-php.ini-on-gitlab-ci
This commit is contained in:
commit
e0d32f4c5a
6 changed files with 77 additions and 99 deletions
|
@ -44,7 +44,7 @@ continuous integration.
|
||||||
|
|
||||||
Introduction
|
Introduction
|
||||||
PHPVersionSupport
|
PHPVersionSupport
|
||||||
TestingFramework
|
ReleaseBranchingStrategy
|
||||||
Environment
|
Environment
|
||||||
DependencyManager
|
DependencyManager
|
||||||
Running
|
Running
|
||||||
|
|
65
Documentation/ReleaseBranchingStrategy.rst
Normal file
65
Documentation/ReleaseBranchingStrategy.rst
Normal file
|
@ -0,0 +1,65 @@
|
||||||
|
.. include:: /Includes.rst.txt
|
||||||
|
|
||||||
|
.. _release-branching-strategy:
|
||||||
|
|
||||||
|
==============================
|
||||||
|
Release and Branching Strategy
|
||||||
|
==============================
|
||||||
|
|
||||||
|
When maintaining TYPO3 extensions, developers often need to support multiple
|
||||||
|
TYPO3 Long-Term Support (LTS) versions simultaneously. This typically requires
|
||||||
|
a clear release and branching strategy to manage development and maintenance
|
||||||
|
across different TYPO3 versions.
|
||||||
|
|
||||||
|
There are two common strategies for managing branches when supporting multiple
|
||||||
|
TYPO3 LTS versions.
|
||||||
|
|
||||||
|
.. contents:: Table of Contents:
|
||||||
|
:backlinks: top
|
||||||
|
:class: compact-list
|
||||||
|
:depth: 2
|
||||||
|
:local:
|
||||||
|
|
||||||
|
.. _release-branching-strategy-one-branch:
|
||||||
|
|
||||||
|
Approach 1: One branch for multiple TYPO3 LTS versions
|
||||||
|
======================================================
|
||||||
|
|
||||||
|
In this approach, there is a single main branch that receives new features and
|
||||||
|
updates, while supporting multiple TYPO3 LTS versions at the same time.
|
||||||
|
|
||||||
|
The downside of this approach is that it may require some version-dependent
|
||||||
|
code switches, which can increase complexity. However, the major advantage is
|
||||||
|
that there is only one branch to maintain, making it easier to implement new
|
||||||
|
features and code changes across all supported TYPO3 versions.
|
||||||
|
|
||||||
|
This approach simplifies the maintenance of the extension and is preferred when
|
||||||
|
minimizing maintenance overhead is the primary concern.
|
||||||
|
|
||||||
|
.. _release-branching-strategy-multiple-branches:
|
||||||
|
|
||||||
|
Approach 2: Separate branch per TYPO3 LTS version
|
||||||
|
=================================================
|
||||||
|
|
||||||
|
In this approach, there is one main branch for each TYPO3 LTS version. This
|
||||||
|
means that each branch exclusively supports a single TYPO3 LTS version.
|
||||||
|
|
||||||
|
The advantage here is that version-specific code can be used without requiring
|
||||||
|
version-dependent switches, reducing complexity in the codebase. However, this
|
||||||
|
approach increases the maintenance burden, as any new features or updates must
|
||||||
|
be applied to each branch individually.
|
||||||
|
|
||||||
|
This approach may be necessary when there are significant differences between
|
||||||
|
TYPO3 LTS versions or when you want to avoid version-dependent code.
|
||||||
|
|
||||||
|
.. _release-strategy-conclusion:
|
||||||
|
|
||||||
|
Conclusion
|
||||||
|
==========
|
||||||
|
|
||||||
|
The appropriate release and branching strategy depends on the specific
|
||||||
|
requirements of the extension and the TYPO3 versions you are supporting. If
|
||||||
|
reducing maintenance complexity is a priority, using a single branch for
|
||||||
|
multiple versions is often the better choice. However, if you need to tailor
|
||||||
|
your extension for each version, a separate branch for each version may be more
|
||||||
|
suitable.
|
|
@ -1,57 +0,0 @@
|
||||||
.. include:: /Includes.rst.txt
|
|
||||||
|
|
||||||
.. _testing-framework:
|
|
||||||
|
|
||||||
=================
|
|
||||||
Testing framework
|
|
||||||
=================
|
|
||||||
|
|
||||||
Extensions usually need to support two LTS versions of TYPO3 in parallel,
|
|
||||||
assuming that they should support all currently supported TYPO3 LTS versions.
|
|
||||||
To achieve this, there are two different approaches, which also affect the
|
|
||||||
choice of a testing framework for unit and functional tests.
|
|
||||||
|
|
||||||
.. contents:: Table of Contents:
|
|
||||||
:backlinks: top
|
|
||||||
:class: compact-list
|
|
||||||
:depth: 2
|
|
||||||
:local:
|
|
||||||
|
|
||||||
.. _testing-framework-approach-many-versions:
|
|
||||||
|
|
||||||
Approach 1: One branch for many TYPO3 LTS versions
|
|
||||||
==================================================
|
|
||||||
|
|
||||||
With this approach, there is one main branch that gets new features. It needs to
|
|
||||||
support two TYPO3 LTS versions in parallel.
|
|
||||||
|
|
||||||
The downside is that this slightly increases code complexity as
|
|
||||||
version-dependent code switches might be necessary. The upside is that there
|
|
||||||
is only one branch to maintain, which makes adding new features (and all other
|
|
||||||
code changes) a lot less of a hassle.
|
|
||||||
|
|
||||||
The `Nimut testing framework <https://github.com/Nimut/testing-framework>`__
|
|
||||||
can support multiple TYPO3 versions at a time, and
|
|
||||||
it provides version-independent abstractions for testing, making it the perfect
|
|
||||||
companion for this approach.
|
|
||||||
|
|
||||||
This is the approach that we have chosen for this extension as we do not want
|
|
||||||
to maintain two branches in parallel.
|
|
||||||
|
|
||||||
.. _testing-framework-approach-one-version:
|
|
||||||
|
|
||||||
Approach 2: One branch per TYPO3 LTS version
|
|
||||||
============================================
|
|
||||||
|
|
||||||
With this approach, there are two main branches that get new features in
|
|
||||||
parallel. Each branch supports exactly one TYPO3 LTS version.
|
|
||||||
|
|
||||||
The upside is that this slightly decreases code complexity as
|
|
||||||
version-dependent code switches are not necessary. The downside is that there
|
|
||||||
are two branches to maintain, which makes adding new features (and all other
|
|
||||||
code changes) more of a hassle.
|
|
||||||
|
|
||||||
For this approach, the
|
|
||||||
`TYPO3 testing framework <https://github.com/TYPO3/testing-framework>`__
|
|
||||||
- which supports only one TYPO3 LTS version at a time - will work just fine.
|
|
||||||
|
|
|
@ -8,6 +8,7 @@ use TTN\Tea\Domain\Model\Tea;
|
||||||
use TTN\Tea\Domain\Repository\TeaRepository;
|
use TTN\Tea\Domain\Repository\TeaRepository;
|
||||||
use TYPO3\CMS\Extbase\Domain\Model\FileReference;
|
use TYPO3\CMS\Extbase\Domain\Model\FileReference;
|
||||||
use TYPO3\CMS\Extbase\Persistence\PersistenceManagerInterface;
|
use TYPO3\CMS\Extbase\Persistence\PersistenceManagerInterface;
|
||||||
|
use TYPO3\CMS\Extbase\Persistence\Repository;
|
||||||
use TYPO3\TestingFramework\Core\Functional\FunctionalTestCase;
|
use TYPO3\TestingFramework\Core\Functional\FunctionalTestCase;
|
||||||
|
|
||||||
/**
|
/**
|
||||||
|
@ -31,6 +32,14 @@ final class TeaRepositoryTest extends FunctionalTestCase
|
||||||
$this->subject = $this->get(TeaRepository::class);
|
$this->subject = $this->get(TeaRepository::class);
|
||||||
}
|
}
|
||||||
|
|
||||||
|
/**
|
||||||
|
* @test
|
||||||
|
*/
|
||||||
|
public function isRepository(): void
|
||||||
|
{
|
||||||
|
self::assertInstanceOf(Repository::class, $this->subject);
|
||||||
|
}
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* @test
|
* @test
|
||||||
*/
|
*/
|
||||||
|
|
|
@ -1,39 +0,0 @@
|
||||||
<?php
|
|
||||||
|
|
||||||
declare(strict_types=1);
|
|
||||||
|
|
||||||
namespace TTN\Tea\Tests\Unit\Domain\Repository;
|
|
||||||
|
|
||||||
use TTN\Tea\Domain\Repository\TeaRepository;
|
|
||||||
use TYPO3\CMS\Extbase\Object\ObjectManagerInterface;
|
|
||||||
use TYPO3\CMS\Extbase\Persistence\Repository;
|
|
||||||
use TYPO3\TestingFramework\Core\Unit\UnitTestCase;
|
|
||||||
|
|
||||||
/**
|
|
||||||
* @covers \TTN\Tea\Domain\Repository\TeaRepository
|
|
||||||
*/
|
|
||||||
final class TeaRepositoryTest extends UnitTestCase
|
|
||||||
{
|
|
||||||
private TeaRepository $subject;
|
|
||||||
|
|
||||||
protected function setUp(): void
|
|
||||||
{
|
|
||||||
parent::setUp();
|
|
||||||
|
|
||||||
if (\interface_exists(ObjectManagerInterface::class)) {
|
|
||||||
$objectManagerStub = $this->createStub(ObjectManagerInterface::class);
|
|
||||||
// @phpstan-ignore-next-line This line is 11LTS-specific, but we're running PHPStan on TYPO3 12.
|
|
||||||
$this->subject = new TeaRepository($objectManagerStub);
|
|
||||||
} else {
|
|
||||||
$this->subject = new TeaRepository();
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
/**
|
|
||||||
* @test
|
|
||||||
*/
|
|
||||||
public function isRepository(): void
|
|
||||||
{
|
|
||||||
self::assertInstanceOf(Repository::class, $this->subject);
|
|
||||||
}
|
|
||||||
}
|
|
|
@ -54,7 +54,7 @@
|
||||||
"php-parallel-lint/php-parallel-lint": "1.4.0",
|
"php-parallel-lint/php-parallel-lint": "1.4.0",
|
||||||
"phpmd/phpmd": "2.15.0",
|
"phpmd/phpmd": "2.15.0",
|
||||||
"phpstan/extension-installer": "1.4.3",
|
"phpstan/extension-installer": "1.4.3",
|
||||||
"phpstan/phpstan": "1.12.5",
|
"phpstan/phpstan": "1.12.6",
|
||||||
"phpstan/phpstan-phpunit": "1.4.0",
|
"phpstan/phpstan-phpunit": "1.4.0",
|
||||||
"phpstan/phpstan-strict-rules": "1.6.1",
|
"phpstan/phpstan-strict-rules": "1.6.1",
|
||||||
"phpunit/phpunit": "9.6.20",
|
"phpunit/phpunit": "9.6.20",
|
||||||
|
@ -62,7 +62,7 @@
|
||||||
"seld/jsonlint": "1.11.0",
|
"seld/jsonlint": "1.11.0",
|
||||||
"spaze/phpstan-disallowed-calls": "3.4.0",
|
"spaze/phpstan-disallowed-calls": "3.4.0",
|
||||||
"squizlabs/php_codesniffer": "3.10.3",
|
"squizlabs/php_codesniffer": "3.10.3",
|
||||||
"ssch/typo3-rector": "2.8.0",
|
"ssch/typo3-rector": "2.9.2",
|
||||||
"ssch/typo3-rector-testing-framework": "2.0.1",
|
"ssch/typo3-rector-testing-framework": "2.0.1",
|
||||||
"symfony/console": "^5.4.44 || ^6.4.12 || ^7.1.5",
|
"symfony/console": "^5.4.44 || ^6.4.12 || ^7.1.5",
|
||||||
"symfony/translation": "^5.4.44 || ^6.4.12 || ^7.1.5",
|
"symfony/translation": "^5.4.44 || ^6.4.12 || ^7.1.5",
|
||||||
|
|
Loading…
Reference in a new issue