The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.We currently "support" upgrades from Panopoly 1.0-rc4 (and all newer versions) to the latest version. This means:
- We run automated upgrade tests from those versions to the latest on every commit
- If we break upgrade from one of those versions to latest, we consider it critical bug that will get fixed before release (and actually as soon as possible, because it breaks our automated testing)
These things consume resources (ie. hours that the maintainers and contributors have for development) and make our automated tests run longer (basically, an extra 50 minutes for each version we support).
We can't continue to support upgrade from every version forever! So, we need to decide on a policy for dropping support for upgrading from old versions.
For the sake of the conversation, I'd like to propose dropping support for versions that were released greater than 1 year ago. Currently, that includes:
| Version | Release date | Usage |
|---|---|---|
| 1.0-rc4 | 2013-04-22 | ~150 sites |
| 1.0-rc5 | 2013-07-31 | ~350 sites |
| 1.1 | 2014-01-29 | ~200 sites |
| 1.2 | 2014-03-08 | ~200 sites |
| 1.4 | 2014-04-24 | ~20 sites |
As far as community process, I'd like to propose:
- When a new release is made, mention the oldest version that we support upgrades from in the release notes, post on groups.drupal.org/panopoly and in the "Updating Panopoly" guide.
- Let's keep a table on the "Updating Panopoly" guide which lists old versions of Panopoly and what is the newest version you can upgrade to
- Once we remove support for upgrade from a particular version, we'll close any bugs in the upgrade path as "Closed (won't fix)"
I'd also like to keep this issue open for 1 month to allow for the maintainers and community to discuss the details of this proposal. Until we make a decision on this, the details are subject to change! For example, we could decide that we keep support upgrades for 1.5 years rather than 1 year, or change the community announcement period, etc..
Comments
Comment #1
mglamanHere's my thought: Panopoly was at 1.0 last January. It is now 1.20. There has been 20 releases, most of which were from security releases - Drupal was at 7.24! So from a profile standpoint I'd say even six months. People are going to need to update Panopoly to update core.
The toolset as a whole I'm not sure. I generally feel that if you're incorporating Panopoly into your own distro you're more advanced or doing something more complicated which has resources to manage frequent maintenance to keep up with changes.
Comment #2
mglamanAnother thought! Panopoly is testing upgrade paths from point to point. Let's document this! With documented upgrade testing site maintainers can "leap frog" releases. Users who are outdated and not in the testing support window can review historical testing information.
Let's say in 1.21 support is killed off for < 1.4 in testing. Fast forward to Panopoly being at 1.25. If a site maintainer on 1.0-rc5 (~350 people) decided to upgrade they would check documentation for last stable upgrade test. They know they can checkout 1.20 and upgrade safely. From there they can checkout 1.25 and upgrade safely to get up to speed.
As stated in the last comment - most releases are due to contrib or core security releases. That means users should be updating pretty often. If the releases are documented I think the window of supporting upgrade paths could be cut down to 6 month windows. Or maybe even "We will support upgrade path testing of the last 8 releases." Defining number of releases versus time window.
Comment #3
dsnopekI think this is a killer idea! Even after upgrade support is dropped, there is still a way for users to get to the latest version, so it shouldn't be as big a deal to drop support for upgrades.
This is also an interesting idea... Then we could say, "It's safe to jump from where you are to 8 releases forward. If you need to go further, do it in jumps of 8 releases or less."
Thanks so much for your input!
Comment #4
populist commentedI think having a time based period (one year) on upgrade support for releases is pretty reasonable. I prefer a time period over a specific number of releases since occasionally we release a bunch of releases for small security fixes which might blow out our limit pretty quickly.
We absolutely want to support legacy users, but chasing down issues from the RC is going to be distracting. Also, as mentioned, you should be able to upgrade to a previous version of Panopoly and then upgrade from there.
This would require adding some information to the Upgrading Panopoly documentation, but that seems pretty basic.
Comment #5
dsnopekThanks, @populist!
Since users can always update in stages, I'm going the community process to be "faster", ie. without a month long waiting period, and clear notes about where/how to document the supported upgrades. Please check out the issue summary!
And, since we're doing a release today or tomorrow for the Views SA, I'll start documenting some of this stuff for this release.
Comment #6
dsnopekIt's been "roughly a month" since opening this issue, so I'm going to go forward with this plan!
Comment #8
dsnopek