Symfony 2.0.5 was released on the 2nd November, including updates to HttpFoundation.

When trying to find out which version of Symfony we are currently using (but it is definitely not that one), I discovered there is no obvious way to get this information from a core checkout. Could we do something like add their changelog to includes/Symfony?

https://github.com/symfony/symfony/blob/2.0/CHANGELOG-2.0.md

CommentFileSizeAuthor
#7 1343160-update-symfony-2-0-10.patch31.29 KBmsonnabaum
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

aspilicious’s picture

What about a small readme that holds the version info in it?

The changelog has to much info.

cosmicdreams’s picture

The yardstick as moved, Symphony is now 2.0.6. How frequently do they put out revisions? Perhaps this issue should be about how we are going to integrate the efforts of this other project.

When d8 is stable, how frequently will we be pulling from upstream? While d8 is in development should we build unit and regression tests around how Drupal uses HttpFoundation and design build process that constantly gets whatever newest release they have?

catch’s picture

Yeah I think we need a plan here as well as an update.

For me personally, my current thinking is I'd like us to keep external libraries up to date as much as humanly possible while D8 is in development. That gives us the earliest possible warning if there is an unexpected bc break, regression, bug fixes that allow us to remove workarounds etc.

The use of external libraries should be covered by unit and functional testing when those patches are introduced (or at worst introduced retrospectively), and an updated patch in the issue queue is enough to run those tests. That stuff is mostly in place.

So the main questions I think are:

1.; Could we possibly set something up to automatically notify us when we fall behind with an external library - could just be a contrib module or a jenkins job (although we'd have to host it somewhere). Either of those could potentially be made to roll the patch and post the issue too if we really wanted.

2. If we don't go for full automation of #1, are there people who'd volunteer to roll those patches and/or subscribe to RSS feeds or whatever.

3. What to do after Drupal 8 releases. jQuery has set a bad precedent in that we pretty much have to leave that out of date in core for the full length of a release cycle (since they tend to break bc in minor releases and other fun stuff). I believe Symfony has a stricter policy than that, so we ought to be able to stay up to date, albeit possibly slightly more conservatively.

catch’s picture

Now on http://symfony.com/blog/symfony-2-0-7-released

That makes us three versions behind.

Crell’s picture

Symfony 2.1 is due in January-ish, I believe. Honestly I'm inclined to leave it as is until then, unless there's a specific bug fix we need, then upgrade to 2.1.

For during the D8 stable cycle, I think Symfony is expected to have an LTS release before then. I'd suggest we track the bugfix releases of that LTS.

RobLoach’s picture

The patch at #1424924: Use Composer for updating Symfony components (without removing Symfony code from repo) includes an update to Symfony 2.1.0, and makes future updates very easy.

msonnabaum’s picture

Status: Active » Needs review
FileSize
31.29 KB

While I agree with Rob that we should use composer for this, here's an update to 2.0.10 to hold us over until we figure that issue out.

Crell’s picture

Status: Needs review » Reviewed & tested by the community

I am not sure this is critical, but it seems to be quite reasonable.

catch’s picture

Status: Reviewed & tested by the community » Fixed

Looks like Dries committed this: http://drupalcode.org/project/drupal.git/commit/87e5ffc

We were running a jQuery version from 2010 until about a couple of months ago in 8.x. We shouldn't ship 8.x with a 2-3 year old version of jQuery, same for Symfony. So I think updating external libraries should count as absolute release blockers until we've got a better way of keeping in sync.

Crell’s picture

Priority: Critical » Normal
Status: Fixed » Active

And this is why we should just be using Composer: http://symfony.com/blog/security-release-symfony-2-0-11-released :-)

(Dropping down from critical because this doesn't break anything and we're over-threshold right now. This issue isn't critical, especially since we are far from release and will be upgrading to 2.1 by then anyway.)

RobLoach’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.