Frogg's web tools

Official website : symfony.com
Official Symfony Github : Symfony on Github
Official Symfony componet Github : Symfony component on Github

Framework definition

In computer science, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. A software framework provides a standard way to build and deploy applications. A software framework is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate development of software applications, products and solutions. Software frameworks may include support programs, compilers, code libraries, tool sets, and application programming interfaces (APIs) that bring together all the different components to enable development of a project or system.

Frameworks have key distinguishing features that separate them from normal libraries:

• inversion of control: In a framework, unlike in libraries or in standard user applications, the overall program's flow of control is not dictated by the caller, but by the framework.
• extensibility: A user can extend the framework - usually by selective overriding; or programmers can add specialized user code to provide specific functionality.
• non-modifiable framework code: The framework code, in general, is not supposed to be modified, while accepting user-implemented extensions. In other words, users can extend the framework, but should not modify its code.

Source : wikipedia

Composer

Symfony dependencies are based on composer, and stored on packagist.org

An article is available and dedicated to composer : tool.frogg.fr composer

IDE phpStorm

Symfony plugin exist for phpStorm to help coding.

An article is available and dedicated to phpStorm : tool.frogg.fr IDE phpStorm

Symfony & Symfony components are using the Semantic Versioning.

Official releases : symfony.com releases
Official roadmap : symfony.com roadmap

Standard Versions (STD)

A Standard Minor Version is maintained for an eight month period for bug fixes, and for a fourteen month period for security issue fixes.

In Symfony 2.x branch, the number of minor versions wasn't constrained, so that branch ended up with nine minor versions (from 2.0 to 2.8). Starting from 3.x branch, the number of minor versions is limited to five (from X.0 to X.4).

Long Term Support Versions (LTS)

Every two years, a new Long Term Support Version (usually abbreviated as "LTS") is published. Each LTS version is supported for a three year period for bug fixes, and for a four year period for security issue fixes.

In the Symfony 2.x branch, the LTS versions are 2.3, 2.7 and 2.8. Starting from the 3.x branch, only the last minor version of each branch is considered LTS (e.g. 3.4, 4.4, 5.4, etc.)

Version timeline

this is a theoretical time line to explain STD & LTS

STD each 6 month (total 2 years)
---|---|---|---|---|--->
  4.0 4.1 4.2 4.3 4.4
  
LTS all 2 years from 3.0 to 4.0 
---|---|---|---|---|---> 3.4 = 4.0
  3.0 3.1 3.2 3.3 3.4
---|---|---|---|---|---> 4.4 = 5.0 ...etc... 
  4.0 4.1 4.2 4.3 4.4 

Editor support

STD got 2 extra months of bug fixes & 6 extra months of security patches
LTS got 1 extra year of bug fixes & 2 extra years of security patches

Backward Compatibility

Symfony Backward Compatibility Promise is very strict and allows developers to upgrade with confidence from one minor version of Symfony to the next one.

Whenever keeping backward compatibility is not possible, the feature, the enhancement or the bug fix will be scheduled for the next major version.

However, Experimental Features are not part of the backward compatibility promise and their APIs can change from one minor version to the next. The changelog must explain the changes and how to upgrade.
Official link : Symfony Backward Compatibility

Symfony upgrade

Upgrading a Minor Version

Official link : Upgrading a Minor Version

There are two steps to upgrading a minor version:

• Update the Symfony library via Composer;
• Update your code to work with the new version.

Upgrading a Major Version

Official link : Upgrading a Major Version

There are a couple of steps to upgrading a major version:

• Make your code deprecation free;
• Update to the new major version via Composer;
• Update your code to work with the new version.

Symfony news

Official link : www.symfony-news.com

Symfony Flex is the name of Symfony version 4.0

Symfony Flex is the new way to install and manage Symfony applications. Flex is not a new Symfony version, but a tool that replaces and improves the Symfony Installer and the Symfony Standard Edition.

Symfony Flex automates the most common tasks of Symfony applications, like installing and removing bundles and other Composer dependencies. Symfony Flex works for Symfony 3.3 and higher. Starting from Symfony 4.0, Flex should be used by default, but it is still optional.

Symfony Flex is a Composer plugin that modifies the behavior of the require, update, and remove commands. When installing or removing dependencies in a Flex-enabled application, Symfony can perform tasks before and after the execution of Composer tasks.

Official link : Symfony Flex

composer unpack

Symfony Flex edit composer code to add a new command (available only for Symfony Flex project) unpack.
This command will allow Symfony to works with recipes.

Official link : Symfony recipes
Official link : Symfony recipes on Github
Official link : Symfony recipes-contrib on Github

These recipes are used to add Alias and .env configuration to the libraries added with composer.
These configuration are automaticaly managed by Symfony, the user should not modify directly the .env files.

More informations on recipes : Symfony Flex

Example

https://github.com/symfony/recipes/blob/master/doctrine/doctrine-bundle/1.6/manifest.json

{
    "bundles": {
        "Doctrine\\Bundle\\DoctrineBundle\\DoctrineBundle": ["all"]
    },
    "copy-from-recipe": {
        "config/": "%CONFIG_DIR%/",
        "src/": "%SRC_DIR%/"
    },
    "env": {
        "#1": "Format described at http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html#connecting-using-a-url",
        "#2": "For an SQLite database, use: \"sqlite:///%kernel.project_dir%/var/data.db\"",
        "#3": "Configure your db driver and server_version in config/packages/doctrine.yaml",
        "DATABASE_URL": "mysql://db_user:db_password@127.0.0.1:3306/db_name"
    }
}

This show the database configuration for Doctrine that will be managed by Symfony unpack command (automatically).