atom.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title><![CDATA[Doctrine]]></title>
    <link href="https://staging.doctrine-project.org/atom.xml" rel="self" />
    <link href="https://staging.doctrine-project.org/" />
    <updated>2024-09-26T16:47:50-04:00</updated>
    <id>https://staging.doctrine-project.org/</id>

            <entry>
            <title type="html"><![CDATA[The skeletons are now out of the closet - So long, Skeleton-Mapper]]></title>
            <link href="https://staging.doctrine-project.org/2024/08/16/the-skeletons-are-now-out-of-the-closet.html"/>
            <updated>2024-08-16T00:00:00-04:00</updated>
            <id>https://staging.doctrine-project.org/2024/08/16/the-skeletons-are-now-out-of-the-closet.html</id>
            <author><name>Claudio Zizza</name></author>
            <content type="html"><![CDATA[<p>While Doctrine ORM and DBAL have a main focus in our daily development, a deeper look
into their dependencies show, that Doctrine has much more projects at hand than just the
database-related ones. Some projects even weren't created for ORM or DBAL, just like
our Skeleton-Mapper.</p>
<p>The <a href="https://github.com/doctrine/skeleton-mapper">Skeleton-Mapper project</a> won't be maintained anymore because of
its lack of usage nowadays and is now an archived repository. The Doctrine Skeleton-Mapper
was an object mapper where you are responsible for implementing the object mapping of the
persistence operations. This means you write plain old PHP code for the data repositories,
object repositories, object hydrators and object persisters. A lot of freedom but also a lot
of work for a developer, including its maintenance for us.</p>
<p>Some projects grow and others become obsolete after some time, which are 9 years in
the case of our Skeleton-Mapper. We also want to express our gratitude to
<a href="https://github.com/doctrine/skeleton-mapper/graphs/contributors">the contributors</a>
and maintainers who kept this project alive for so long. Thank you.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[Doctrine Core Team Meetup 2024 in Bonn, Germany]]></title>
            <link href="https://staging.doctrine-project.org/2024/07/09/doctrine-core-team-meetup.html"/>
            <updated>2024-07-09T00:00:00-04:00</updated>
            <id>https://staging.doctrine-project.org/2024/07/09/doctrine-core-team-meetup.html</id>
            <author><name>Benjamin Eberlei</name></author>
            <content type="html"><![CDATA[<p>We are organizing another Doctrine Core Team Meetup in Bonn, Germany from Tuesday,
8.10.2024 to Thursday, 10.10.2024 at the offices of one of our
sponsors Tideways GmbH.</p>
<p>The goal is to get the current team together, discuss and work on Doctrine DBAL, ORM and ODM.</p>
<p>We thank all of our GitHub and OpenCollective sponsors for making this possible.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[Doctrine ORM 3 and DBAL 4 Released]]></title>
            <link href="https://staging.doctrine-project.org/2024/02/03/doctrine-orm-3-and-dbal-4-released.html"/>
            <updated>2024-02-03T00:00:00-05:00</updated>
            <id>https://staging.doctrine-project.org/2024/02/03/doctrine-orm-3-and-dbal-4-released.html</id>
            <author><name>Jonathan H. Wage</name></author>
            <content type="html"><![CDATA[<p>We are thrilled to announce the release of Doctrine ORM 3.0 and DBAL 4.0.
These releases are the culmination of over a decade of hard work across
dozens of contributors and the Doctrine maintainers.</p>
<h2>What's New</h2>
<p><strong>A Slimmer, More Efficient ORM</strong>: The new Doctrine ORM 3.0 comes in at
326KB, down from 400KB in ORM 2.18.0. This reduction not only makes the
ORM lighter but also signals our efforts to streamline and optimize every
aspect of our library and focus our maintenance efforts on the core functionality
of an ORM and less on tooling and helpers that are only useful by a small number
of our users.</p>
<p><strong>Enhanced Code Quality and Coverage</strong>: With ORM 3.0, we've pushed our
code coverage from 84% to 89%. For DBAL 4.0, we've pushed our code coverage
from 86% to 94%. This improvement underscores our commitment to reliability
and the stability of the Doctrine ecosystem, ensuring that your applications
run smoothly.</p>
<p><strong>Leaner Dependencies</strong>: In Doctrine ORM 3.0, we have finally eliminated
dependencies on <code>doctrine/cache</code> and <code>doctrine/common</code>. This change reduces
complexity and improves maintainability of Doctrine as we now depend on
<a href="https://www.php-fig.org/psr/psr-6/">PSR-6: Caching Interface</a> for our
caching responsibilities. Implementing a PSR means we are more interoperable
with other frameworks and easier to use by a broader amount of users.</p>
<p><strong>A Growing Community</strong>: The Doctrine project now boasts 1029 contributors
across all its projects. This vibrant community is the backbone of Doctrine,
providing valuable insights, feedback, and contributions that drive the
project forward.</p>
<h2>Upgrading</h2>
<p>We understand that upgrading to a new major version can be difficult. The
best way to upgrade is to first upgrade to the latest Doctrine ORM 2.x and
DBAL 3.x version and address any deprecation warnings that are reported. You
can read more about how Doctrine handles deprecations <a href="https://www.doctrine-project.org/policies/deprecation.html">here</a>.
Once you have addressed all of the deprecations, you should have a clear
path to upgrade.</p>
<p>In addition to that, we've maintained comprehensive documentation about
every change, deprecation and BC break to facilitate a smooth transition
to ORM 3.0 and DBAL 4.0.</p>
<ul>
<li><a href="https://github.com/doctrine/orm/blob/3.0.x/UPGRADE.md">Upgrade to Doctrine ORM 3.0</a></li>
<li><a href="https://github.com/doctrine/dbal/blob/4.0.x/UPGRADE.md">Upgrade to Doctrine DBAL 4.0</a></li>
</ul>
<h2>The Future of Doctrine ORM 2</h2>
<p>We plan to maintain Doctrine ORM 2 for at least the next 2 years by providing
bug and security fixes. We may also add or deprecate things in 2.x to improve
the existing forward-compatbility layer to make the transition to ORM 3 smoother.</p>
<h2>Looking Forward</h2>
<p>ORM 3 and DBAL 4 are a big step forward towards modernizing the API of our
libraries, increasing safety with the use of scalar types in the code base,
better error handling and generally cleaning up the code to make it easier
to maintain. We look forward to continuing work on Doctrine and focusing on
being the most stable and reliable PHP database persistence related libraries
available.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[Archiving Unmaintained Packages]]></title>
            <link href="https://staging.doctrine-project.org/2024/01/30/archiving-unmaintained-packages.html"/>
            <updated>2024-01-30T00:00:00-05:00</updated>
            <id>https://staging.doctrine-project.org/2024/01/30/archiving-unmaintained-packages.html</id>
            <author><name>Andreas Braun</name></author>
            <content type="html"><![CDATA[<p>After long consideration, we have decided to archive a number of repositories that have not seen any activity in a
while. This affects the CouchDB and OrientDB ODMs and their respective libraries, as well as the KeyValueStore project.
The following repositories and composer packages are affected:</p>
<ul>
<li><a href="https://github.com/doctrine/couchdb-client">doctrine/couchdb</a></li>
<li><a href="https://github.com/doctrine/couchdb-odm">doctrine/couchdb-odm</a></li>
<li><a href="https://github.com/doctrine/DoctrineCouchDBBundle">doctrine/couchdb-odm-bundle</a></li>
<li><a href="https://github.com/doctrine/orientdb-odm">doctrine/orientdb-odm</a></li>
<li><a href="https://github.com/doctrine/KeyValueStore">doctrine/key-value-store</a></li>
</ul>
<p>The composer packages will remain available and installable, but we will not be making any bug fixes or security fixes
in the affected libraries. If you or your business depends on one of these libraries, please fork them and maintain them
yourself in the future.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[ORM 3.0 Beta 1, DBAL 4 RC 1 and future plans]]></title>
            <link href="https://staging.doctrine-project.org/2023/10/11/orm3-beta1-dbal4-rc1-future-plans.html"/>
            <updated>2023-10-11T00:00:00-04:00</updated>
            <id>https://staging.doctrine-project.org/2023/10/11/orm3-beta1-dbal4-rc1-future-plans.html</id>
            <author><name>Benjamin Eberlei</name></author>
            <content type="html"><![CDATA[<p>We have released the <a href="https://github.com/doctrine/orm/releases/tag/3.0.0-beta1">first beta of the long awaited Doctrine ORM
3</a> and a <a href="https://github.com/doctrine/dbal/releases/tag/4.0.0-RC1">release
candidate of DBAL 4</a>. </p>
<p>The target audience for these releases are framework integration and extension
library authors. ORM 3 is not yet production ready and the APIs may change.</p>
<p>Our goal is to release ORM 3.0 as soon as possible and to gather feedback from
greenfield project authors first. </p>
<p>This beta release is the result of a lot of work by many contributors,
especially Grégoire, Alexander, Claudio and Matthias on ORM, Sergei and
Alexander on DBAL.  To iron out the final details, we met in Düsseldorf for a
Doctrine Core Team meeting, generously funded by our sponsors through
OpenCollective and GitHub. We also welcomed Matthias as the latest member of
the Doctrine Core Team.</p>
<h3>Continued ORM 2 support and forward compatibility</h3>
<p>We will maintain the latest branch of the 2 line in ORM for at least another 2
years, possibly longer, to give you enough time to upgrade and us more time to
learn from upgrader feedback and improve forward compatibility.</p>
<p>This means that we will be making ORM 2.x work with newer versions of PHP,
fixing security bugs, and introducing layers and features that help with
forward compatibility in the upgrade path to ORM 3. </p>
<p>Current users of ORM 2 should note that there is no urgency right now to update
to ORM 3, as we are still working on replacement APIs and forward
compatibility, and do not intend to ship them all with ORM 3.0, but with later
versions.</p>
<h3>ORM 2 users can already prepare for 3 by addressing deprecations</h3>
<p>But there is already work to be done as an ORM 2 user: to help you find all the
places where things may be deprecated or changing behaviour, we have created
<a href="https://github.com/doctrine/deprecations#usage-from-consumer-perspective">the doctrine/deprecations
library</a>
and integrated it heavily into DBAL, ORM and other components.</p>
<p>It allows the use of deprecated behaviour to be logged at runtime with low
overhead, automatic suppression of the same deprecation occurring multiple
times, and a way to ignore selected deprecations for the time being. Each
deprecation message always links to a GitHub issue with more details.</p>
<p>Many deprecated features have no replacement, such as Mapping Exporters,
Generate Mapping from Database, Named Queries. </p>
<p>For some of the deprecations in ORM, we are still planning replacement APIs,
especially:</p>
<ul>
<li>There is currently no way to limit the number of entities that the flush
operation considers changed. Flush will currently always calculate change
sets on all entities that are not read-only. </li>
<li>As a replacement for removing PARTIAL object hydration, we are looking at
making embeddable objects lazy, perhaps improving nesting of the new DTO
expression in DQL. We are also looking to introduce subselect or batch
loading for collections for more efficient multi-level hydration.</li>
</ul>
<p>These will be released in 2.x as forward compatible APIs so that you can switch
to using them before upgrading to ORM 3.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[Doctrine ORM Team Meetup in Bonn, Germany]]></title>
            <link href="https://staging.doctrine-project.org/2023/08/21/doctrine-orm-team-meetup.html"/>
            <updated>2023-08-21T00:00:00-04:00</updated>
            <id>https://staging.doctrine-project.org/2023/08/21/doctrine-orm-team-meetup.html</id>
            <author><name>Benjamin Eberlei</name></author>
            <content type="html"><![CDATA[<p>We are organizing a Doctrine ORM Core Team Meetup in Düsseldorf, Germany from Monday,
9.10.2023 to Wednesday, 11.10.2023 at the offices of one of our primary
sponsors Tideways GmbH.</p>
<p>The goal is to get the current team together, discuss and work on the missing
pieces for the long-awaited Doctrine ORM 3.0 release that is planned for later
this year.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[From annotations to attributes]]></title>
            <link href="https://staging.doctrine-project.org/2022/11/04/annotations-to-attributes.html"/>
            <updated>2022-11-04T00:00:00-04:00</updated>
            <id>https://staging.doctrine-project.org/2022/11/04/annotations-to-attributes.html</id>
            <author><name>Grégoire Paris</name></author>
            <content type="html"><![CDATA[<p>Last month, we migrated the tests of the ORM from annotations to attributes.
Let us look back on what lead to this moment.</p>
<h2>Annotations</h2>
<p>Let's go 22 years back in time. In October 2000, Ulf Wendel introduces phpdoc
comments at the PHP-Kongress. These comments follow a structure that allows
to produce API documentation from them. They are inspired by javadoc.</p>
<p>In 2002, Alex Buckley, a Specification lead for the Java language publishes
<a href="https://www.cs.ubc.ca/~gregor/teaching/cpsc411/metadata-public-draft.html">JSR-175</a>, thus proposing to add user-defined annotations to the
language, allowing to tag language elements with extra information. 2 years
later, it gets approved and Java 1.5, also known as Java 5 is released, <a href="https://docs.oracle.com/javase/1.5.0/docs/guide/language/annotations.html">with
support for annotations</a>.</p>
<p>4 more years elapse and in 2006, Jano Suchal publishes <a href="https://github.com/jsuchal/addendum">Addendum</a>, a
PHP library that adds support for using &quot;Docblock/JavaDoc&quot; as annotations,
meaning that contrary to what is done in Java, Addendum annotations are
contained inside phpdoc comments, like this:</p>
<pre><code class="language-php">/** @test */
function test_it_throws_on_invalid_argument(): void
{}</code></pre>
<p>That is because they are implemented in userland, without requiring a change in
PHP itself.</p>
<p>Doctrine ORM 2.0 is not released yet at that point, but <a href="https://github.com/doctrine/orm/commit/bcf0110249978c8fc705916d5a4f94216bb98b07">the library is used to
build an annotation driver</a> in Doctrine 2 in early 2009.
At that time, Doctrine was a project in a single repository, with <code>Common</code>,
<code>DBAL</code> and <code>ORM</code> as top-level namespaces.
<a href="https://github.com/doctrine/orm/commit/9075f10bf5da3058f6ef82ff08e4783ff70424a4">Addendum is replaced 6 months later</a>, with a new namespace
under <code>Common</code> called <code>Annotations</code>.</p>
<p>In the summer of 2010, Guilherme Blanco and Pierrick Charron submit
<a href="https://wiki.php.net/rfc/annotations">an RFC to add annotations support to PHP</a>, but it
<a href="https://externals.io/message/49733">gets declined</a>. The RFC already mentions the
need for annotations in PHPUnit, Symfony, Zend Framework, FLOW3 and of course,
Doctrine.</p>
<p>Late 2010, Doctrine 2 is tagged, and the single repository is split into 3
repositories.</p>
<p>Finally, in 2013, the namespace above is isolated in its own repository, and
<code>doctrine/annotations</code> 1.0.0 is tagged.</p>
<p>Today, the package is widely used in the PHP ecosystem and has a little short
of 300 million downloads on Packagist, and is depended on by over 2 thousand
packages, including major frameworks and tools. It is fair to say annotations
have proven valuable to many users.</p>
<h2>Attributes</h2>
<p>The RFC mentioned above is only one among <a href="https://wiki.php.net/rfc">many</a>. As mentioned
before, annotations were implemented as phpdoc comments, which has several
drawbacks:</p>
<ul>
<li>The comments are necessary to run the code, and <a href="https://www.php.net/manual/en/opcache.configuration.php#ini.opcache.save-comments">need to be kept in the
opcode cache</a>.</li>
<li>They are obtained at runtime, by using the reflection API, and because of
that, can only be detected as invalid at runtime.</li>
<li>They are not well supported by IDEs if at all.</li>
<li>They clutter comments, which were originally intended for humans.</li>
<li>They can be confused with phpdoc, which are something else entirely.</li>
</ul>
<p>In March 2020, Benjamin Eberlei resurrects <a href="https://wiki.php.net/rfc/attributes">Dmitry Stogov's attributes
RFC</a> and submits <a href="https://wiki.php.net/rfc/attributes_v2">the seventh RFC on this
topic</a>, introducing attributes to PHP.</p>
<p>A few rounds of RFCs about syntax later, PHP 8.0 is released, with a notable
feature missing: nested attributes. PHP 8.0 attributes use a syntax that is
forward-compatible with them though, and finally, with PHP 8.1, nested
attributes are supported.</p>
<h2>Migrating from one to the other</h2>
<p>Since attributes are much better than annotations, with <code>doctrine/orm</code> 3.0,
annotations will no longer be supported, which means applications using them as
a way to map entities to tables need to migrate towards attributes (or another
driver).
As maintainers of that library, even we needed to migrate: most of the test
suite of <code>doctrine/orm</code> used annotations.</p>
<p>Enter <a href="https://github.com/rectorphp/rector">Rector</a>. Rector is a standalone tool that is invaluable when it
comes to performing such migrations: it is able to understand PHP code and
apply so-called Rectors to it. It is extensible, so it is possible to define
such Rectors in order to address upgrades for anything, including Doctrine.</p>
<p>What's more, it comes with batteries included: when you install
<code>rector/rector</code>, what you get is code from <code>rector/rector-src</code> <em>and</em> its official
extensions, among which you will find <a href="https://github.com/rectorphp/rector-doctrine"><code>rector/rector-doctrine</code></a>.
That's right, there is already an entire extension dedicated to Doctrine.</p>
<p>Rules are grouped together in sets, and the set that interests us here is
<code>Rector\Doctrine\Set\DoctrineSetList::ANNOTATIONS_TO_ATTRIBUTES</code>.</p>
<p>To migrate <code>doctrine/orm</code>'s test suite to annotations, here is how we
proceeded:</p>
<ol>
<li>Install Rector: <code>composer require --dev rector/rector</code>.</li>
<li>
<p>Create a file called <code>rector.php</code> at the root of the library with the
following contents:</p>
<pre><code class="language-php">    &lt;?php

    declare(strict_types=1);

    use Rector\Config\RectorConfig;
    use Rector\Doctrine\Set\DoctrineSetList;

    return function (RectorConfig $rectorConfig): void {
        $rectorConfig-&gt;paths([
            __DIR__ . '/tests',
        ]);
        $rectorConfig-&gt;sets([
            DoctrineSetList::ANNOTATIONS_TO_ATTRIBUTES,
        ]);
    };</code></pre>
</li>
<li>Run <code>vendor/bin/rector</code>, which obeys the above configuration.</li>
<li>Uninstall Rector: <code>composer remove rector/rector &amp;&amp; rm rector.php</code></li>
<li>Run <code>vendor/bin/phpcbf</code> to make the migrated codebase compliant with our
coding standard.</li>
</ol>
<p>Or at least, it was the plan, because some annotations were not perfectly
migrated. All in all, I found only <a href="https://github.com/rectorphp/rector/issues/7528">2</a> <a href="https://github.com/rectorphp/rector-src/pull/2988">bugs</a>, which looks great
given how so many edge cases should appear in our test suite.</p>
<p>I went on and reported those 2 bugs, and this is where the experience went from
great to stellar:
the issue template leads to <a href="https://getrector.org/demo">a playground</a>, much like the one you can
find for other tools such as Psalm or PHPStan.</p>
<p>This one comes with 2 buttons: &quot;Create an issue&quot;, which pre-fills the Github
issue with useful information, and &quot;Create a test&quot;, that lets you create a test
in the right directory (and also, the right repository, which is
<code>rectorphp/rector-src</code>, and not <code>rectorphp/rector</code>).</p>
<p>If you want to add a new test for the bug you reported, you should let
<a href="https://github.com/rectorphp/rector/blob/main/docs/how_to_add_test_for_rector_rule.md">the official tutorial</a> walk you through that, it is very
well written.</p>
<p>Anyway, now that these 2 bugs are fixed and you know how to migrate, plan that
migration, and let us know how it goes! Happy Rectoring!</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[New Release: Doctrine DBAL 3.4.0]]></title>
            <link href="https://staging.doctrine-project.org/2022/08/06/dbal-3.4.0.html"/>
            <updated>2022-08-06T00:00:00-04:00</updated>
            <id>https://staging.doctrine-project.org/2022/08/06/dbal-3.4.0.html</id>
            <author><name>Sergei Morozov</name></author>
            <content type="html"><![CDATA[<p>Doctrine is proud to announce the release of Doctrine DBAL 3.4.0. Below is a summary of the most noteworthy changes
in the new release:</p>
<h2>Database schema introspection optimization (<a href="https://github.com/doctrine/dbal/pull/5268">#5268</a>)</h2>
<p>Older DBAL versions, in order to introspect database schema, performed a set of queries for each table individually.
This caused noticeable performance issues on some platforms like Oracle which seemingly rebuild their internal views
for each such query.</p>
<p>As of this release, the entire schema is introspected in a fixed number of queries. The more tables the schema contains,
the more noticeable this optimization should be.</p>
<p>It was impossible to make these optimizations while using the schema introspection platform methods
(e.g. <code>getListTableColumnsSQL()</code>). As a result, although these methods are kept in the codebase for backward
compatibility, the DBAL itself no longer uses them. The SQL queries used for schema introspection are no longer
considered part of the public DBAL API.</p>
<h2>Support for foreign key constraints on SQLite (<a href="https://github.com/doctrine/dbal/pull/5427">#5427</a>)</h2>
<p>Although SQLite has supported foreign key constraints since its earliest versions, their support in the DBAL
was quite limited. One of the reasons for that was that managing foreign key constraints in SQLite is quite different
from the rest of the supported platforms.</p>
<p>For example, when a foreign key constraint is declared, platforms like MySQL require that the referenced table
must already exist. To support creating tables with mutually referencing constraints, the DBAL would
create the tables first and create the constraints via <code>ALTER TABLE … ADD FOREIGN KEY …</code>.</p>
<p>This approach doesn't work with SQLite since it doesn't allow adding constraints to an existing table. Fortunately,
it doesn't require the referenced table to exist at the time of creating the foreign key either.</p>
<p>The new DBAL release introduces a new API for building <code>CREATE TABLE</code> and <code>DROP TABLE</code> statements for multiple tables
which could be tailored to the requirements of a given platform. The <code>AbstractPlatform::supportsForeignKeys()</code> method
is now deprecated since the DBAL supports foreign key constraints on all supported platforms.</p>
<h2>Support for TEXT/BLOB default values on MariaDB (<a href="https://github.com/doctrine/dbal/pull/5332">#5332</a>)</h2>
<p>The platform layer in the DBAL is organized in the way that the code implementing the support for MySQL is also
used to support MariaDB. As a result, even though MariaDB may support certain features the DBAL doesn't support them
because they are not supported by MySQL. One of such features is the default values for TEXT and BLOB columns.</p>
<p>As of the new release, the default TEXT and BLOB values are supported on MariaDB but are still unsupported on MySQL,
even though MySQL supports them as of
release <a href="https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-data-types">8.0.13</a>.</p>
<h2>Support for result caching in QueryBuilder (<a href="https://github.com/doctrine/dbal/pull/5539">#5539</a>)</h2>
<p>The recently added <code>enableResultCache()</code> method of the <code>QueryBuilder</code> class allows specifying the query cache profile
to be used for performing the queries built by the builder.</p>
<h2>PHP 7.4 or newer is required (<a href="https://github.com/doctrine/dbal/pull/5459">#5459</a>)</h2>
<p>The DBAL no longer supports PHP 7.3 since its support by the community ended last year. The codebase now
actively uses such features of PHP 7.4 as
<a href="https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters">covariant return types</a>
and <a href="https://wiki.php.net/rfc/typed_properties_v2">typed properties</a>.</p>
<h2>Deprecations</h2>
<p>In light of the DBAL 4 release planned for later this year, the 3.4.0 release introduces over 30 deprecations which,
as usual, focus on cleaning up obsolete features and making the API more robust and clearer from the
static analysis standpoint.</p>
<p>To learn more about upgrading your application, see the
<a href="https://github.com/doctrine/dbal/blob/3.4.0/UPGRADE.md#upgrade-to-34">upgrade notes</a>. You can find the full
list of changes in the release <a href="https://github.com/doctrine/dbal/milestone/107">milestone</a>.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[On Doctrine Sponsoring with the help of OpenCollective]]></title>
            <link href="https://staging.doctrine-project.org/2022/03/24/opencollective.html"/>
            <updated>2022-03-24T00:00:00-04:00</updated>
            <id>https://staging.doctrine-project.org/2022/03/24/opencollective.html</id>
            <author><name>Benjamin Eberlei</name></author>
            <content type="html"><![CDATA[<p>To simplify our own administrative burden, we have decided to move over the
funds to <a href="https://opencollective.com/doctrine">OpenCollective</a>, primarily
motivated by the success and positive experience of the new PHP Foundation.</p>
<p>We have started raising money for the Doctrine Project in 2019 through Patreon and
Github Sponsors to support the project. It was planned to organize core team
get-togethers/hackathons, but due to the pandemic we haven't been able to do this.
In addition the legal and tax implications of raising money also caused us
some headaches. </p>
<p>The move to OpenCollective will allow us to delegate much of the administrative
work to them for a small percentage of the raised capital. The fee is a much
smaller amount than the taxes that we had to pay on the raised money
previously, so it is a win-win for us.</p>
<p>We want to assure our sponsors that we still plan to make use of the funds
to further the Doctrine project and we are actively looking to increase our funding
for these goals:</p>
<ul>
<li>
<p>Regularly organize hackathons for Doctrine Core team contributors, including
3-4 days of accommodation, food and travel for roughly 10-15 people.</p>
</li>
<li>
<p>Infrastructure, servers and hosting.</p>
</li>
<li>
<p>Marketing material such as stickers, t-shirts and other small things.</p>
</li>
<li>
<p>If the budget increases significantly we might be able to pay someone part-
or full-time to do maintenance work such as responding to and processing
issues, prepare for new PHP releases and general cleanups of the codebase.</p>
</li>
</ul>
<p>As such we hope to convince you to sponsor Doctrine through either our <a href="https://github.com/sponsors/doctrine/">Github
Sponsors</a> or
<a href="https://opencollective.com/doctrine">OpenCollective</a> directly.</p>]]></content>
        </entry>
            <entry>
            <title type="html"><![CDATA[Sunsetting Doctrine DBAL 2]]></title>
            <link href="https://staging.doctrine-project.org/2022/01/22/sunsetting-dbal-2.html"/>
            <updated>2022-01-22T00:00:00-05:00</updated>
            <id>https://staging.doctrine-project.org/2022/01/22/sunsetting-dbal-2.html</id>
            <author><name>Sergei Morozov</name></author>
            <content type="html"><![CDATA[<p>Since the release of <a href="https://github.com/doctrine/dbal/releases/tag/3.0.0">Doctrine DBAL 3.0.0 </a> in November 2020,
the 2.x release series effectively went into the maintenance mode. In the past year, we've been accepting mostly
the following types of patches for DBAL 2:</p>
<ol>
<li>Development dependency updates</li>
<li>Security fixes</li>
<li>Improvements to compatibility with PHP 8.1</li>
<li>Improvements in the upgrade path to DBAL 3</li>
</ol>
<p>Except for dependency updates, at the moment, there are no known issues in DBAL 2 that would fall into any of
the above categories.</p>
<p>Many projects that depend on Doctrine DBAL depend on it indirectly via Doctrine ORM which until
<a href="https://github.com/doctrine/orm/releases/tag/2.10.0">release 2.10.0</a> didn't support DBAL 3.
It was one of the blockers of the DBAL 3 adoption which is no longer the case.</p>
<p>With all that said, the DBAL team announces the plan for sunsetting DBAL 2 in 6 months as of the ORM 2.10.0 release
which is April 3, 2022. After that date, we plan to release DBAL 2 only to address security related
and other critical issues for at most a year.</p>
<p>All Doctrine DBAL users are encouraged to upgrade to the latest stable version
which is <a href="https://github.com/doctrine/dbal/releases/tag/3.3.0">3.3.0</a> as of the time of this writing.</p>
<p>For migrating from DBAL 2 to 3, see our two blog posts on DBAL 2.13 Forward Compatibility Layer:</p>
<ul>
<li><a href="https://www.doctrine-project.org/2021/03/29/dbal-2.13.html">New Release: Doctrine DBAL 2.13 with Deprecations and Forward Compatibility</a></li>
<li><a href="https://www.doctrine-project.org/2021/04/19/dbal-2.13.1-3.1.0.html">New Release: Doctrine DBAL 2.13.1 and 3.1.0 with important Forward Compatibility fix</a></li>
</ul>]]></content>
        </entry>
    </feed>