Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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
Comment | File | Size | Author |
---|---|---|---|
#7 | 1343160-update-symfony-2-0-10.patch | 31.29 KB | msonnabaum |
Comments
Comment #1
aspilicious CreditAttribution: aspilicious commentedWhat about a small readme that holds the version info in it?
The changelog has to much info.
Comment #2
cosmicdreams CreditAttribution: cosmicdreams commentedThe 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?
Comment #3
catchYeah 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.
Comment #4
catchNow on http://symfony.com/blog/symfony-2-0-7-released
That makes us three versions behind.
Comment #5
Crell CreditAttribution: Crell commentedSymfony 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.
Comment #6
RobLoachThe 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.
Comment #7
msonnabaum CreditAttribution: msonnabaum commentedWhile 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.
Comment #8
Crell CreditAttribution: Crell commentedI am not sure this is critical, but it seems to be quite reasonable.
Comment #9
catchLooks 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.
Comment #10
Crell CreditAttribution: Crell commentedAnd 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.)
Comment #11
RobLoach#1424924: Use Composer for updating Symfony components (without removing Symfony code from repo)