proper prefixes for cookie options
Use addPrefix to avoid deprecated calls in >2.2.0
merged branch davedevelopment/mount-with-prefix (PR #643)

This PR was merged into the master branch.

Commits
-------

36b879b Use addPrefix to avoid deprecated calls in >2.2.0

Discussion
----------

Use addPrefix to avoid deprecated calls in >2.2.0

I think this should take care of #642
Force travis to use 2.1.*
merged branch davedevelopment/force-travis-2.1 (PR #644)

This PR was merged into the master branch.

Commits
-------

e11b93e Force travis to use 2.1.*

Discussion
----------

Force travis to use 2.1.* now 2.2 has a stable release
merged branch indeyets/session-doc-fix (PR #633)

This PR was merged into the master branch.

Commits
-------

eb941a8 proper prefixes for cookie options

Discussion
----------

All cookie-related options of NativeSessionStorage should be prefixed with `cookie_`

---------------------------------------------------------------------------

by indeyets at 2013-02-16T09:25:59Z

Separate issue is, that there are, actually, much more options available. Listing all of those wouldn't be useful for this doc, so I skipped it for now.

---------------------------------------------------------------------------

by igorw at 2013-02-16T15:33:22Z

The doc should probably link to http://php.net/session.configuration

---------------------------------------------------------------------------

by igorw at 2013-03-05T02:30:32Z

@indeyets what's the status on this? can you update your patch with the link?
added a note about all possible options for the session (refs #633)
Add support for remember-me with RememberMeServiceProvider
merged branch GromNaN/remember-me (PR #645)

This PR was squashed before being merged into the master branch (closes #645).

Commits
-------

adc172b Add support for remember-me with RememberMeServiceProvider

Discussion
----------

Add support for remember-me with RememberMeServiceProvider

This is a refactoring of #464.

I made a separate service provider to avoid adding more complexity to the SecurityServiceProvider.
Add services allowing for form type extensions and guessers
merged branch davedevelopment/form-extension-points (PR #553)

This PR was squashed before being merged into the master branch (closes #553).

Commits
-------

7c38c9a Add services allowing for form type extensions and guessers

Discussion
----------

Add services allowing for form type extensions and guessers

I don't like the empty `FormTypeGuesserChain`, but `PreloadedExtension` requires one to be passed until symfony/symfony#5479 gets merged.

---------------------------------------------------------------------------

by fabpot at 2012-11-24T11:54:08Z

symfony/symfony#5479 has been merged now.

---------------------------------------------------------------------------

by davedevelopment at 2012-11-25T19:59:41Z

So, do we want this documenting at this point? I'm glad to have removed the dummy TypeGuesser, but without it, people who don't have a 'dev' version of symfony/form, will need the workaround in their userland code, which may cause headaches.

---------------------------------------------------------------------------

by fabpot at 2013-01-10T07:34:15Z

I think we need to switch to Symfony 2.2 in Silex now. What others think? @igorw

---------------------------------------------------------------------------

by davedevelopment at 2013-01-10T07:54:20Z

:+1: from me, though while we're on the topic, are there any plans to tag a 1.0?

---------------------------------------------------------------------------

by igorw at 2013-01-10T13:52:38Z

@fabpot Is there any reason why you would want to enforce users to use an unstable version?

I am against it for the following reasons:

* Users should be able to get stable versions if the stable versions work correctly.
* Silex already allows you to get 2.2, simply by lowering the `minimum-stability` to `beta`.
* Our current recommended way to install silex is `1.0.*@dev` (except on the download page, because it was not updated correctly when we changed it). This means that once they update it will blow up (due to `minimum-stability`), which will result in a lot of frustration, and a lot of support requests.

IMO we should encourage our users to try 2.2 by lowering their `minimum-stability`, but not enforce it.

---------------------------------------------------------------------------

by stof at 2013-01-10T13:55:34Z

another solution would be to bump the requirement to 2.2 only after releasing Silex.

---------------------------------------------------------------------------

by fabpot at 2013-01-11T07:51:36Z

Silex has not reached 1.0 yet. So, switching to 2.2 seems logical to me. That being said, we can wait for 2.2 stable to be out if this is what you suggest.

---------------------------------------------------------------------------

by igorw at 2013-01-11T16:23:06Z

Bumping to 2.2 after it is stable sounds acceptable to me, but unless there is a specific change in 2.2 that silex *needs*, I still don't really see the point. Supporting 2.1+ is easy enough to do.

---------------------------------------------------------------------------

by davedevelopment at 2013-03-06T13:28:19Z

So the current status with this PR, is that adding a TypeExtension with anything less than 2.1.4 of the symfony components will break, unless the user also adds an FormTypeGuesserChain to the guessers array. That is, the test `testFormServiceProviderWillLoadTypeExtensions` will fail with symfony/form < 2.1.4.

If we want to merge this in I guess we can:

* Document the whole feature, with a note/gotcha for Symfony <2.1.4
* Bump the minimum Symfony component versions to 2.1.4
* Just merge it anyway

---------------------------------------------------------------------------

by stof at 2013-03-06T14:13:38Z

bumping to 2.1.4 as minimum is fine IMO. I don't see why someone would want to use 2.1.0 explicitly instead of using the bufix releases for 2.1

---------------------------------------------------------------------------

by fabpot at 2013-03-06T21:39:29Z

:+1: for bumping to 2.1.4+

---------------------------------------------------------------------------

by igorw at 2013-03-06T22:08:37Z

In this particular case I'd say it's acceptable to bump to `2.1.4`.

In the future these kind of changes will need more consideration though, as they can cause BC issues when multiple branches of symfony are supported by silex.

---------------------------------------------------------------------------

by fabpot at 2013-03-08T12:05:04Z

When we said bumping to 2.1.4, I thought we were talking about bumping for just the component that has problems with earlier Symfony version, not all of them.

---------------------------------------------------------------------------

by davedevelopment at 2013-03-08T12:14:06Z

I did that because I wasn't sure how to approach it, I'll have a think about it, but I'll probably need some guidance.

I guess we may have to fall back on documenting that we have a dependency on 2.1.4 version of the Form Component, because it's not actually required? Maybe that should be in `suggest`? I don't think suggest enforces version requirements, so it either needs to be in the suggest message, or in the docs?

---------------------------------------------------------------------------

by igorw at 2013-03-08T12:22:59Z

It should be in both. Specifically, the form service provider docs.

---------------------------------------------------------------------------

by davedevelopment at 2013-03-08T13:01:26Z

Changed the requirements bump and documented, do we need to have something more specific/wordy in the docs?

Squashed a little as well, can squash further if it's desirable.
Added a note about writing documentation
merged branch davedevelopment/add-doc-info-to-docs (PR #647)

This PR was merged into the master branch.

Commits
-------

6a4fffe Added a note about writing documentation

Discussion
----------

Added a note about writing documentation

---------------------------------------------------------------------------

by igorw at 2013-03-08T15:52:03Z

:+1: