why do we maintain duplicate "lib" code base and run checkSameCodeBase tests?

[fermulator]

during #312 I noticed the build failed on this weird test called check-same-code-base, there is no CONTRIBUTING.md file, so I really couldn't know what this is all about

loaded the test, and eventually saw some "interesting" validation happening
checked previous PRs that went in, and confirmed the "insanity" -- for every diff to some files, the ./Lib/... file too needs to be updated!?!?

I'd like to first understand context/reasoning here ... why couldn't we just keep the lib code, and delete the duplication in the other files?

If there is truly a reason (guessing legacy), then it would be great to add a contributing file, and in doing so explain this requirement; (probably too the test should log more details about what needs to happen)

[MorrisJobke]

I'd like to first understand context/reasoning here ... why couldn't we just keep the lib code, and delete the duplication in the other files?

Because we build based on the actual files in this repo. There is one CLI tool, that is build from the lib folder and single web based updater in index.php. To keep the crucial part in sync we added this check. Yes it's duplication, but it served us well so far. Then the integrity of each version (stableXX) is inside the git repo and not behind another build step that depends on specific PHP versions and build tools.

[fermulator]

Interesting. I think I am still not quite in understanding. Why couldn't both the cli and the web based updater use/share the lib/* version of the code? Are there scenarios/cases where somehow they are required to be out of sync?

[MorrisJobke]

Interesting. I think I am still not quite in understanding. Why couldn't both the cli and the web based updater use/share the lib/* version of the code? Are there scenarios/cases where somehow they are required to be out of sync?

The idea is to have the updater always be a single file (for the web part and for the cli part), that cannot be only halfway copied. Therefore we made to disadvantage of the need to copy the code in this repo, but the updater shouldn't change that often anyways. In that way also one can point to this repo and say "use this version" and it would simply be this single file and not multiple files that need to be updated in sync.

[fermulator]

interesting - so what is this use for "here's the updater as 1 file drop"? some sort of bug chicken/egg problem where customer can't upgrade to get the latest version of the updater so fix the bug there then replace that one file?

[MorrisJobke]

some sort of bug chicken/egg problem where customer can't upgrade to get the latest version of the updater so fix the bug there then replace that one file?

Yes that was the idea - we never needed this in the past 4 years, but that was the initial concept. Sure - we maybe can re-evaluate this, unfortunately we are quite busy in other parts of Nextcloud right now and there was no pressure to change this working component so fundamentally, so we kept it.

[fermulator]

If beneficial, I'd be happy to "delete all the duplicate code", and add the appropriate refs/deps to leverage utils. (but would only initiate on that effort if maintainers agree)

[come-nc]

Documented by #503

We keep a duplicated version of the code to make sure the updater is a single file and reduce potential issues.