[#15965] - Deleted files for 3.8
- Fixed in Code Base
- 11 May 2017
- Medium
- Build: 3.8-dev
- # 15965
- Diff
- mbabker:3.8-deleted-files
User tests: Successful: Unsuccessful:
Summary of Changes
I had someone helping me with some basic router testing/review over the weekend and one of the things they noticed was that even though they applied the 3.8 upgrade (from the nightly builds), the version was still at 3.7 and this is because all of the files that have been renamed haven't been added to the deleted files array yet. So, this catches us up so we can more adequately test "real" upgrades.
Testing Instructions
Review the added file list and make sure it matches up with the current 3.8-dev branch. I ran git diff tags/3.7.0 3.8-dev --name-status > 3.8-diff.txt to get a list of files to work from.
Expected result
Old files deleted on upgrade.
Actual result
Old files not yet deleted.
Documentation Changes Required
N/A
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_admin |
wilsonge
- | Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-05-11 13:31:28 |
| Closed_By | ⇒ | wilsonge | |
| Labels |
Added:
?
|
||
Not sure I'm understanding you here. The packages are built just fine, but for users testing updates, if that array isn't populated they won't have a state that matches what's in the repo now. That's the issue I ran into with someone over the weekend, and that's why I caught that array up to where we're at now.
Yes. I get that. But IIRC there was a decision that we don't need to add the files to that array (on that branch) as this can done by the git diff. But i can remember it wrong.
No, there is no automated process to build the deleted files list right now. It'd be nice if we had one, but until there is, someone has to do the hard work.
While packaging we run a git diff and write a couple of files containing lists of added/modified files and deleted files, but that shouldn't be altering anything in the final distribution (remember the packages are based on a git tag, if we package a code change that isn't part of the git tag that can be problematic).
No, there is no automated process to build the deleted files list right now. It'd be nice if we had one, but until there is, someone has to do the hard work.
Sure. I know this but then we also need to check 4.0..
While packaging we run a git diff and write a couple of files containing lists of added/modified files and deleted files, but that shouldn't be altering anything in the final distribution
I know this was just the idea to limit the load of one PR. But we can stop accepting that kind of PRs and force them to add the correct the script file too. Maybe the reason was merge conflicts with that file?
We aren't doing it on 4.0 right now because there is a lot more happening there, and let's be honest, how many people are actually going into the update component and testing updates from 3.x to 4.0 right now versus either grabbing a nightly build or running from git? For 3.7 to 3.8, it's more practical that we're going to have people updating so having this step done as we go is going to be more important (as in we can't wait for the first beta release to update the file).
Yes, the file hits merge conflicts quite frequently, not much that we can do about that unless someone's offering to rewrite the core update handling to handle deleted files in a different manner.
Wasn't that the credo we had about the dev versions that we want to catch that up using git diff?