User tests: Successful: 0 Unsuccessful: 0
Change type of field "value" in table #_fields_values
from text to mediumtext for MySQL ONLY. PostgreSQL have only text field type with unlimited length. Pull Request for Issue #36065
Status | New | ⇒ | Pending |
Category | ⇒ | SQL Administration com_admin Installation Postgresql |
@sergeytolkachyov Meanwhile 5.0.x is in stable phase, so I think this PR here should be made for the 5.1-dev branch. Could you rebase your PR or redo it for 5.1-dev?
Labels |
Added:
PR-5.0-dev
|
Category | SQL Administration com_admin Installation Postgresql | ⇒ | SQL Administration com_admin Installation |
@sergeytolkachyov Meanwhile 5.0.x is in stable phase, so I think this PR here should be made for the 5.1-dev branch. Could you rebase your PR or redo it for 5.1-dev?
Is this such a big change that it should only be in the minor version?
Is this such a big change that it should only be in the minor version?
@sergeytolkachyov I will ask other maintainers or release managers for their opinion. Stay tuned.
@sergeytolkachyov Meanwhile 5.0.x is in stable phase, so I think this PR here should be made for the 5.1-dev branch. Could you rebase your PR or redo it for 5.1-dev?
Is this such a big change that it should only be in the minor version?
it's a feature and not a bugfix that's the reason why it should go into 5.1.
If you follow the semver, minor releases should include changes that do not lead to loss of backward compatibility and lead to the appearance of new functionality. While minor changes, bug fixes should be included in the patch version. As a result of applying the changes from this PR, nothing new will appear for either developers or users. The bug described in the issue will only be fixed.
Why is this a feature? Maybe for languages using the Latin alphabet, this is a feature - an increase in the amount of data for the field. But for languages where letters are stored in unicode, this is rather a bug fix, since it was impossible to store a large amount of data in the field values.
There is really no big difference when it will be enabled: in 5.0.3 or in 5.1. I just want to understand the logic.
everything which is not a bug is a feature, if you follow this you simple reduce the pain to upgrade. security stuff is another topic and a change like this doesn't need to hurry since you can fix it for your sites your self.
@sergeytolkachyov Meanwhile 5.0.x is in stable phase, so I think this PR here should be made for the 5.1-dev branch. Could you rebase your PR or redo it for 5.1-dev?
Is this such a big change that it should only be in the minor version?
it's a feature and not a bugfix that's the reason why it should go into 5.1.
It seems to have done a rebase...
It seems to have done a rebase...
@sergeytolkachyov Yes. Now the PR shows more changes than only yours, and there are conflicts, but I think that should be solved with the next upmerge from 5.0-dev to 5.1-dev by the release managers and then updating your branch to the 5.1-dev.
In addition it needs to rename the update SQL script, see my review comment.
So maybe it's easier if you just close this PR and make a new one for the 5.1-dev branch.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2024-01-04 10:25:10 |
Closed_By | ⇒ | sergeytolkachyov |
Category | SQL Administration com_admin Installation | ⇒ | Unit Tests Administration SQL com_admin com_joomlaupdate com_menus com_templates Language & Strings Repository NPM Change External Library Composer Change Installation |
Thanks.
Because J5.0.2 now is RC I moved it to 5.0.3.