fixed some grammar + tweaks
added support to lock vendors as they are currently checked out
removed ending 's'
reverted sentence
updated VENDORS for 2.0.1
updated vendors to dev branches
updated assetic to v1.0.2
Fixed configuration for doctrine caching
merged branch krymen/config_fix (PR #189)

Commits
-------

f134e9f Fixed configuration for doctrine caching

Discussion
----------

Fixed configuration for doctrine caching
merged branch kriswallsmith/2.0 (PR #182)

Commits
-------

4cd7a27 updated assetic to v1.0.2

Discussion
----------

Assetic 1.0.2

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

by lsmith77 at 2011/09/01 14:16:57 -0700

dupe of #181
bumped version of dependencies
bumped version of Swiftmailer
use the BC branch
Remove checks for SQLite
merged branch alexandresalome/remove-sqlite-dependency (PR #203)

Commits
-------

e6e8d30 Remove checks for SQLite

Discussion
----------

Remove checks for SQLite

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

by lsmith77 at 2011/09/16 07:00:17 -0700

I guess this PR depends on https://github.com/symfony/symfony/pull/2195 ?

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

by alexandresalome at 2011/09/16 07:10:52 -0700

@lsmith77 : Thanks for noticing !
Adjust the way of checking for windows
merged branch Seldaek/wintest (PR #204)

Commits
-------

25846a1 Adjust the way of checking for windows

Discussion
----------

Adjust the way of checking for windows
merged branch schmittjoh/patch-1 (PR #199)

Commits
-------

a65eec7 use the BC branch

Discussion
----------

use the BC branch

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

by fabriceb at 2011/09/14 02:01:37 -0700

The most dangerous BC breaks are those which change the configuration settings (which Johannes just did in JMSSecurityExtraBundle). Because you might update all the dependencies to their correct versions, and still have a major break in your application because of a configuration parameter not in the new format.

I am therefore strongly in favor of fixing all revisions of all bundles in the Symfony standard edition.

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

by stof at 2011/09/14 05:11:12 -0700

@fabriceb The SE comes with locked version in deps.lock which should be used.

@schmittjoh you need to check the version in deps.lock

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

by mbadolato at 2011/09/14 09:26:49 -0700

The SE (at least the github download) has deps.lock updates to it that break the distribution. There were changes yesterday (to a few dependancies) and Twig broke, for instance. Also, until yesterdays updates, it was locked at 2.0.0 and not the current 2.0.1 release.

Should the github repository no longer be used for SE downloads, making the packaged download the only real distribution? That's fine if it is, I'm just curious because I track the Git repository and still do merge updates to my project when I see them, to ensure I'm staying current with SE. So, if I need to stop doing that and just wait for packaged release, I can do that.  My question to packaged releases, though, is when update s are done, can we rely on just updating deps and deps.lock, or will we also need to update things in app/ and bin/ etc?

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

by stof at 2011/09/14 09:43:50 -0700

@mbadolato Use the 2.0 branch of the symfony-standard repo if you want to use the BC version, or keep the released version.
For 2.0.x releases, the deps and deps.lock should be enough. For 2.1, you will maybe need some changes in the config but this will be documented when it will be released.
updated vendors
merged branch lsmith77/vendors_lock (PR #167)

Commits
-------

fe13c82 added support to lock vendors as they are currently checked out

Discussion
----------

added support to lock vendors as they are currently checked out

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

by brikou at 2011/07/30 05:46:33 -0700

+1

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

by lsmith77 at 2011/09/05 10:18:44 -0700

@fabpot: would really be nice to have this merged. seems quite low risk and highly useful.

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

by jmikola at 2011/09/05 12:37:55 -0700

Reading the diff is a bit confusing, but is this just a new command option to update the deps.lock file without doing anything else? If so, it sounds worthwhile.

Would this help folks that have reported accidentally losing their local changes in vendor directories?

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

by lsmith77 at 2011/09/05 12:41:54 -0700

yes, all it adds is a new ``bin/vendor lock`` command.
use case is the following: you manually check out a newer version or branch of a vendor, or you even commit into the vendor. then once you are done you want to lock exactly the version of the code you currently have checked out.

right now you will have to either manually do ``git log`` and copy the hash into ``deps.lock`` or run ``bin/vendor update`` and then revert whatever lines you dont want updated in ``deps.lock`` risking that in case you have uncommitted changes in any of the vendors that those changes will be lost.