citus
citus copied to clipboard
Prefer make install-all instead of make-install in docs
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 Report
Merging #4082 into master will increase coverage by
0.00%
. The diff coverage isn/a
.
@@ Coverage Diff @@
## master #4082 +/- ##
=======================================
Coverage 90.69% 90.70%
=======================================
Files 186 186
Lines 35762 35762
=======================================
+ Hits 32436 32437 +1
+ Misses 3326 3325 -1
Hey All, what is our final decision here?
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
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:
- A single package containing only downgrade scripts called
citus-downgrades
, for every citus release we update this one. -
citus-9.4
depends oncitus-downgrades>=9.4
,citus-9.5
depends oncitus-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.
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.
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.
Btw, make check
(in the root Makefile) depends on make install
which removes the downgrade scripts. That's rather confusing.