2.0 standards

[Daniel Leech]

Hello,

We are now effectively working on the 2.0 release and have the
opportunity to make some changes to our general standards, the following
things have occured to me:

- Do not use "compact" bundle file structure (use src/ and test/ directories);
Currently we mix the "meta", code and test files in the same
directory. This is messy and ultimately restrictive.

- Drop PHP 5.4 support;
Use new array syntax on *new* libraries.

- Use of separate libraries for heavy integrations;
For example in Resource at the moment we face having to require
both Sylius and Sonata as dev-dependencies, in addition to ultimately
requiring both Doctrine ORM, ODM and future object mapper support.

We have discussed some of this before, and we can surely add to these
points, so just wanted to open a discussion with the view of laying
down a wiki page.

Cheers,

Dan

[Lukas Kahwe Smith]

> On 26 May 2016, at 11:35, Daniel Leech <dan...@dantleech.com> wrote:
>
> Hello,
>
> We are now effectively working on the 2.0 release and have the
> opportunity to make some changes to our general standards, the following
> things have occured to me:
>
> - Do not use "compact" bundle file structure (use src/ and test/ directories);
> Currently we mix the "meta", code and test files in the same
> directory. This is messy and ultimately restrictive.

I have no preference here

> - Drop PHP 5.4 support;
> Use new array syntax on *new* libraries.

imho PHP 5.5

> - Use of separate libraries for heavy integrations;
> For example in Resource at the moment we face having to require
> both Sylius and Sonata as dev-dependencies, in addition to ultimately
> requiring both Doctrine ORM, ODM and future object mapper support.

I am not sure I understand how this exactly solves things ..

> We have discussed some of this before, and we can surely add to these
> points, so just wanted to open a discussion with the view of laying
> down a wiki page.
>
> Cheers,
>
> Dan
>

> --
> You received this message because you are subscribed to the Google Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to symfony-cmf-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[Daniel Leech]

On Thu, May 26, 2016 at 11:42:58AM +0200, Lukas Kahwe Smith wrote:
>
> > On 26 May 2016, at 11:35, Daniel Leech <dan...@dantleech.com> wrote:
> >
> > Hello,
> >
> > We are now effectively working on the 2.0 release and have the
> > opportunity to make some changes to our general standards, the following
> > things have occured to me:
> >
> > - Do not use "compact" bundle file structure (use src/ and test/ directories);
> > Currently we mix the "meta", code and test files in the same
> > directory. This is messy and ultimately restrictive.
>
> I have no preference here
>
> > - Drop PHP 5.4 support;
> > Use new array syntax on *new* libraries.
>
> imho PHP 5.5

+1

>
> > - Use of separate libraries for heavy integrations;
> > For example in Resource at the moment we face having to require
> > both Sylius and Sonata as dev-dependencies, in addition to ultimately
> > requiring both Doctrine ORM, ODM and future object mapper support.
>
> I am not sure I understand how this exactly solves things ..

Benefits of separate packages as I see it:

- Faster composer installs during development.
- Less risk of conflicts.
- Problems are multipled every time you need to support a new
integration - it doesn't scale well.
- Abiltity to have non-stable integrations whilst releasing a stable
version of the main package.
- Ability to focus on a specific problem (e.g. Sonata integration) rather
than trying to bend the host libraries infrastructure to accomodate
it.

For travis we could still composer-require them during the build.

[GMX - Maximilian Berghoff]

Am 26.05.2016 um 11:42 schrieb Lukas Kahwe Smith:
>> On 26 May 2016, at 11:35, Daniel Leech <dan...@dantleech.com> wrote:
>>
>> Hello,
>>
>> We are now effectively working on the 2.0 release and have the
>> opportunity to make some changes to our general standards, the following
>> things have occured to me:
>>
>> - Do not use "compact" bundle file structure (use src/ and test/ directories);
>> Currently we mix the "meta", code and test files in the same
>> directory. This is messy and ultimately restrictive.
> I have no preference here

I have. I think as one organisation we should use same structure. That
is easier for new contributors. Maybe we should always have a look at
symfony directory structure.

>
>> - Drop PHP 5.4 support;
>> Use new array syntax on *new* libraries.
> imho PHP 5.5

:+1: I think it's same for symfony 3 so should change that when doing
the symfony 3 migration on each bundle/component
"::class" is a nice feature we can/schould/have to use then.

>
>> - Use of separate libraries for heavy integrations;
>> For example in Resource at the moment we face having to require
>> both Sylius and Sonata as dev-dependencies, in addition to ultimately
>> requiring both Doctrine ORM, ODM and future object mapper support.

There are pro's and contra's:
pro:
- single responsibility on package layer
- usable parts for non symfony apps
contra:
- hard for feature implementation across 2 or more packages packages
- which package to require?

[Daniel Leech]

On Thu, May 26, 2016 at 01:19:24PM +0200, GMX - Maximilian Berghoff wrote:
>
>
> Am 26.05.2016 um 11:42 schrieb Lukas Kahwe Smith:
> >> On 26 May 2016, at 11:35, Daniel Leech <dan...@dantleech.com> wrote:
> >>
> >> Hello,
> >>
> >> We are now effectively working on the 2.0 release and have the
> >> opportunity to make some changes to our general standards, the following
> >> things have occured to me:
> >>
> >> - Do not use "compact" bundle file structure (use src/ and test/ directories);
> >> Currently we mix the "meta", code and test files in the same
> >> directory. This is messy and ultimately restrictive.
> > I have no preference here
> I have. I think as one organisation we should use same structure. That
> is easier for new contributors. Maybe we should always have a look at
> symfony directory structure.

I am proposing here that we change all the file structures. I believe
Symfony is like it is is because of the subtree split.

> >
> >> - Drop PHP 5.4 support;
> >> Use new array syntax on *new* libraries.
> > imho PHP 5.5
> :+1: I think it's same for symfony 3 so should change that when doing
> the symfony 3 migration on each bundle/component
> "::class" is a nice feature we can/schould/have to use then.
> >
> >> - Use of separate libraries for heavy integrations;
> >> For example in Resource at the moment we face having to require
> >> both Sylius and Sonata as dev-dependencies, in addition to ultimately
> >> requiring both Doctrine ORM, ODM and future object mapper support.
> There are pro's and contra's:
> pro:
> - single responsibility on package layer
> - usable parts for non symfony apps

These parts are not intended to be used by other applications, they are
dependant on the main package.

> contra:
> - hard for feature implementation across 2 or more packages packages
> - which package to require?

You require the packages that you need, e.g. if you are using
SonataAdmin and Doctrine ORM, and we provide integrations for each of
those, then you require `.../resource-description-sonata` and
`.../resource-storage-orm`.

[gmx Privat]

> Am 26.05.2016 um 16:42 schrieb Daniel Leech <dan...@dantleech.com>:
>
>> On Thu, May 26, 2016 at 01:19:24PM +0200, GMX - Maximilian Berghoff wrote:
>>
>>
>> Am 26.05.2016 um 11:42 schrieb Lukas Kahwe Smith:
>>>> On 26 May 2016, at 11:35, Daniel Leech <dan...@dantleech.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> We are now effectively working on the 2.0 release and have the
>>>> opportunity to make some changes to our general standards, the following
>>>> things have occured to me:
>>>>
>>>> - Do not use "compact" bundle file structure (use src/ and test/ directories);
>>>> Currently we mix the "meta", code and test files in the same
>>>> directory. This is messy and ultimately restrictive.
>>> I have no preference here
>> I have. I think as one organisation we should use same structure. That
>> is easier for new contributors. Maybe we should always have a look at
>> symfony directory structure.
>
> I am proposing here that we change all the file structures. I believe
> Symfony is like it is is because of the subtree split.

Can you give an example what you propose?

[Daniel Leech]

On Thu, May 26, 2016 at 05:56:52PM +0200, gmx Privat wrote:
>
> > Am 26.05.2016 um 16:42 schrieb Daniel Leech <dan...@dantleech.com>:
> >
> >> On Thu, May 26, 2016 at 01:19:24PM +0200, GMX - Maximilian Berghoff wrote:
> >>
> >>
> >> Am 26.05.2016 um 11:42 schrieb Lukas Kahwe Smith:
> >>>> On 26 May 2016, at 11:35, Daniel Leech <dan...@dantleech.com> wrote:
> >>>>
> >>>> Hello,
> >>>>
> >>>> We are now effectively working on the 2.0 release and have the
> >>>> opportunity to make some changes to our general standards, the following
> >>>> things have occured to me:
> >>>>
> >>>> - Do not use "compact" bundle file structure (use src/ and test/ directories);
> >>>> Currently we mix the "meta", code and test files in the same
> >>>> directory. This is messy and ultimately restrictive.
> >>> I have no preference here
> >> I have. I think as one organisation we should use same structure. That
> >> is easier for new contributors. Maybe we should always have a look at
> >> symfony directory structure.
> >
> > I am proposing here that we change all the file structures. I believe
> > Symfony is like it is is because of the subtree split.
>
> Can you give an example what you propose?

src/
tests/
composer.json
README.md
.travis.yml
.gitignore

>
> >>>
> >>>> - Drop PHP 5.4 support;
> >>>> Use new array syntax on *new* libraries.
> >>> imho PHP 5.5
> >> :+1: I think it's same for symfony 3 so should change that when doing
> >> the symfony 3 migration on each bundle/component
> >> "::class" is a nice feature we can/schould/have to use then.
> >>>
> >>>> - Use of separate libraries for heavy integrations;
> >>>> For example in Resource at the moment we face having to require
> >>>> both Sylius and Sonata as dev-dependencies, in addition to ultimately
> >>>> requiring both Doctrine ORM, ODM and future object mapper support.
> >> There are pro's and contra's:
> >> pro:
> >> - single responsibility on package layer
> >> - usable parts for non symfony apps
> >
>

[gmx Privat]

:+1: completely dacore.
Maybe an bin/ or a dest/ and the bundle inside src/

[Daniel Leech]

I started a wiki page:

https://github.com/symfony-cmf/symfony-cmf/wiki/Release-2.0-Standards

and added:

- Minimum symfony version as 2.8;
- Using PSR-4;
- Removing the %parameters% in DI XML config files;

please feel free to add to the list and discuss here (maybe it would be
better as a PR on the docs?)

[Daniel Leech]

Just realised I duplicated the role of the "Release 2.0 Planning" page,
I have updated that instead:

https://github.com/symfony-cmf/symfony-cmf/wiki/Release-2.0

[Wouter de Jong]

I've updated the article a bit:

• Current bundles cannot update their syntax to PHP 5.5, as it causes many merge conflicts (with the minor resources we have, we have to keep maintaince as easy as possible). These packages should be updated to PHP 5.5 when CMF 1.x support is dropped (which is when Symfony 2.7 reaches eom)
• PSR-4 is already implemented
• Many proposals are accepted and described into the notes already
• I think you meant class parameters with "Removing the %parameters% from the DI XML files" (parameters in general can still be used)

[Daniel Leech]

Updated again - tidied up and added some examples.

On Fri, May 27, 2016 at 11:52:23PM +0200, Wouter de Jong wrote:
> I've updated the article a bit:
>

> * Current bundles cannot update their syntax to PHP 5.5, as it causes

> many merge conflicts (with the minor resources we have, we have to
> keep maintaince as easy as possible). These packages should be updated
> to PHP 5.5 when CMF 1.x support is dropped (which is when Symfony 2.7
> reaches eom)

> * PSR-4 is already implemented
> * Many proposals are accepted and described into the notes already
> * I think you meant class parameters with "Removing the %parameters%

> from the DI XML files" (parameters in general can still be used)
>

> 2016-05-27 11:18 GMT+02:00 Daniel Leech <[1]dan...@dantleech.com>:
>
> Just realised I duplicated the role of the "Release 2.0 Planning" page,
> I have updated that instead:
>

>     [2]https://github.com/symfony-cmf/symfony-cmf/wiki/Release-2.0

> On Fri, May 27, 2016 at 09:55:52AM +0100, Daniel Leech wrote:
> > I started a wiki page:
> >
> >   

>  [3]https://github.com/symfony-cmf/symfony-cmf/wiki/Release-2.0-Standards

> >
> > and added:
> >
> > - Minimum symfony version as 2.8;
> > - Using PSR-4;
> > - Removing the %parameters% in DI XML config files;
> >
> > please feel free to add to the list and discuss here (maybe it would
> be
> > better as a PR on the docs?)
> >
> > On Thu, May 26, 2016 at 06:36:22PM +0200, gmx Privat wrote:
> > >
> > >
> > > > Am 26.05.2016 um 18:03 schrieb Daniel Leech

> <[4]dan...@dantleech.com>:

> > > >
> > > >> On Thu, May 26, 2016 at 05:56:52PM +0200, gmx Privat wrote:
> > > >>
> > > >>>> Am 26.05.2016 um 16:42 schrieb Daniel Leech

> <[5]dan...@dantleech.com>:

> > > >>>>
> > > >>>> On Thu, May 26, 2016 at 01:19:24PM +0200, GMX - Maximilian
> Berghoff wrote:
> > > >>>>
> > > >>>>
> > > >>>> Am 26.05.2016 um 11:42 schrieb Lukas Kahwe Smith:
> > > >>>>>> On 26 May 2016, at 11:35, Daniel Leech

> send an email to [7]symfony-cmf-de...@googlegroups.com.
> > > >> For more options, visit [8]https://groups.google.com/d/optout.

> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> > > > To unsubscribe from this group and stop receiving emails from it,

> send an email to [9]symfony-cmf-de...@googlegroups.com.
> > > > For more options, visit [10]https://groups.google.com/d/optout.

> > >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> > > To unsubscribe from this group and stop receiving emails from it,

> send an email to [11]symfony-cmf-de...@googlegroups.com.
> > > For more options, visit [12]https://groups.google.com/d/optout.

> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> > To unsubscribe from this group and stop receiving emails from it, send

> an email to [13]symfony-cmf-de...@googlegroups.com.
> > For more options, visit [14]https://groups.google.com/d/optout.

>
> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to [15]symfony-cmf-de...@googlegroups.com.
> For more options, visit [16]https://groups.google.com/d/optout.

>
> --
> You received this message because you are subscribed to the Google Groups
> "symfony-cmf-devs" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to [17]symfony-cmf-de...@googlegroups.com.
> For more options, visit [18]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:dan...@dantleech.com
> 2. https://github.com/symfony-cmf/symfony-cmf/wiki/Release-2.0
> 3. https://github.com/symfony-cmf/symfony-cmf/wiki/Release-2.0-Standards
> 4. mailto:dan...@dantleech.com
> 5. mailto:dan...@dantleech.com
> 6. mailto:dan...@dantleech.com
> 7. mailto:symfony-cmf-devs%2Bunsu...@googlegroups.com
> 8. https://groups.google.com/d/optout
> 9. mailto:symfony-cmf-devs%2Bunsu...@googlegroups.com
> 10. https://groups.google.com/d/optout
> 11. mailto:symfony-cmf-devs%2Bunsu...@googlegroups.com
> 12. https://groups.google.com/d/optout
> 13. mailto:symfony-cmf-devs%2Bunsu...@googlegroups.com
> 14. https://groups.google.com/d/optout
> 15. mailto:symfony-cmf-devs%2Bunsu...@googlegroups.com
> 16. https://groups.google.com/d/optout
> 17. mailto:symfony-cmf-de...@googlegroups.com
> 18. https://groups.google.com/d/optout