[#13661] - [RFC] Manage Database Change Deltas Correctly For Proper Upgrade Paths
- Closed
- 10 Apr 2017
- Medium
- Build: staging
- # 13661
The Joomla project has elected to not support any upgrade path except for an upgrade from a stable release package to the package to be tested. It does not offer support for upgrades between nightly builds or pre-stable release packages to newer packages.
There is only one reason this upgrade path is not supported, that is because database change deltas are mismanaged. If managed correctly, this claim of unsupported upgrade path can go away.
This can be addressed with the following changes to the management of this repository:
- When a pull request is merged containing database changes, the files should be renamed to match the merge date. This is actually a better behavior as it will indicate the changes were included into the CMS repository versus the date the contributor made the changes, which as demonstrated, can be a several month discrepancy and result in an out-of-sequence changeset.
- A change delta cannot be modified once it is included in a git tag, regardless of stability level. Yes, this does mean they can be changed which would break nightly build upgrades, but the project should not make it explicitly difficult to test upgrades or upgrade a site through development releases.
joomla-cms-bot
- | Labels |
Added:
?
|
||
It doesn't have to be explicitly supported, but there are small steps that can be taken to avoid a plethora of issues that all boil down to "You upgraded from a non-stable package? 
good luck!"
This issue outlines them.
is not only to
avoid a plethora of issues
is for let more easy to test and attract more tester even not big expert
Any other feedback? Right now my impression is retain the status quo because "meh, who needs more work".
It's fine for me to change it.
would be cool if we could move to something that allows us to create migrations like phinx, but in general I support the idea
franz-wohlkoenig
- | Category | ⇒ | com_joomlaupdate |
| Status | New | ⇒ | Discussion |
Seems the status quo is preferred. Closing in disappointment.
| Status | Discussion | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-04-10 12:16:19 |
| Closed_By | ⇒ | mbabker |
I wouldn't close this. Realistically I wouldn't expect it to change for the 3.7.0 release at that state (since it would be broken already anyway).
I would look ahead for the next releases (3.7.1, 3.8.0) to change that workflow instead.
I agree the dates should match. I don't agree that we should explicitly offer support. For example when we reworked the field types into plugin and killed the gallery plugin we would have had to add support to uninstall a plugin then reinstall it with a different ID and params and for most people they would have had an empty id never used. Whilst we should make it largely possible by editing dates etc. we still should not explicitly offer support so we can make the kind of changes required like in the fields plugin dev work