Prefer make install-all instead of make-install in docs

[onurctirtir]

Users need to install downgrade scripts as well for multi_extension test to pass. Fixes https://github.com/citusdata/citus/issues/4081

Maybe we can consider backporting this to release-9.3 & release-9.4 branches ?

[codecov[bot]]

Codecov Report

Merging #4082 into master will increase coverage by 0.00%. The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #4082   +/-   ##
=======================================
  Coverage   90.69%   90.70%           
=======================================
  Files         186      186           
  Lines       35762    35762           
=======================================
+ Hits        32436    32437    +1     
+ Misses       3326     3325    -1     

[metdos]

Hey All, what is our final decision here?

[onurctirtir]

As far as I understand from above discussions, we have two options:

https://github.com/citusdata/citus/pull/4082#discussion_r466202263

1- When creating downgrade packages, we have to use make install-downgrades, we can't use make install-all when following the standard packaging pipeline. The only place where make install-all becomes useful is to see regression tests to pass. Is it correct ? @JelteF

Assuming it's the case, first option is to separate downgrade tests and adding an optional output for the case that user didn't install downgrade scripts.

Also, along with that change, to ensure that we don't break downgrade logic in any pr, we should make a small change in our CI scripts to ignore/delete that optional test output so that we won't miss any failure in our downgrade logic.

After doing those, we can safely remove make install-all.

https://github.com/citusdata/citus/pull/4082#discussion_r466951116

2- Other option is first to communicate with Devrim and learn that if they will maintain downgrade packages in pgdg. If they won't, then we can simply remove make install-downgrades along with make install-all, install downgrade/upgrade scripts with make install and make the packaging related changes in our packaging pipeline. In that case, we won't need to add any alternative test outputs etc.

---

To me, the second one seems to be a more accurate solution if pgdg already won't maintain our downgrade packages. If you think that we should follow the second approach, then I can communicate with Devrim. What do you think ? @marcocitus @JelteF @onderkalaci

[JelteF]

I think communicating with Devrim would we good to do first. This likely clears up any theoretical packaging problems. If he doesn't want to maintain downgrade packages, I think it makes sense to ask him if it's a problem for him to use another target than plain make install, but instead make install-without-downgrades (or something). Then devs and users that build from source can use plain make install. And users of pgdg packages will still be able to install the downgrade packages from our repos, in case they want to downgrade. If pgdg packages would contain the downgrade scripts there would be a conflict when installing our downgrade packages.

To be clear the ideal scenario packaging wise would be this:

1. A single package containing only downgrade scripts called citus-downgrades, for every citus release we update this one.
2. citus-9.4 depends on citus-downgrades>=9.4, citus-9.5 depends on citus-downgrades>=9.5

This way whenever a user would install a new citus package, they would also pull in the downgrade scripts to be able to downgrade back. Then when they install a lower citus version again, the previously installed citus-downgrades package will be there.

[onurctirtir]

Brainstorming on the options we have a bit more:

@JelteF commented 21 hours ago If he doesn't want to maintain downgrade packages, I think it makes sense to ask him if it's a problem for him to use another target than plain make install, but instead make install-without-downgrades (or something).

I think we can still continue not to install downgrade scripts with make install but split the downgrade tests from multi_extension and adding an alternative output for downgrade tests. My consideration is not to make them deal with a different make target for upgrade packages actually.

So, from my perspective, the steps to be taken after asking Devrim if they will maintain our downgrade packages were as below:

Either our downgrade packages will be maintained in pgdg or not:

• We should remove make install-all
• We should keep make install-downgrades as is and so neither us nor pgdg team won't need to change packaging pipeline for upgrade packages. But we should split the downgrade tests from multi_extension.sql and add an alternative output for that.

[hanefi]

Jelte and I had a brief discussion and dismissed the idea to have alternative test outputs in https://github.com/citusdata/citus/pull/4004#discussion_r452700499

However, we can still do that. I suggest we wait until we hear from @devrimgunduz before making any changes that can potentially break PGDG packages.

@metdos is there any other way we can contact Devrim? He hasn't responded to us since September 21st.

[marcocitus]

Btw, make check (in the root Makefile) depends on make install which removes the downgrade scripts. That's rather confusing.