RFC: app/compose: Add --legacy to start deprecation process #1739
Conversation
First, start printing the current mode we're operating in. This will make it clear from the output if the default changes. Second, add a new `--legacy` switch that users can use today to explicit opt into the current default. And third, start emitting a warning if neither `--legacy` nor `--unified-core` is given. The way I'm thinking we can do this is (timespans flexible of course): - next 6 months: print warning unless mode is explicitly chosen - following 6 months: change default, print deprecation warning if `--legacy` is given - afterwards: remove `--legacy`, gradually clean up code, and profit
| opt_unified_core ? "unified core" : "legacy"); | ||
|
|
||
| if (!opt_print_only && !opt_unified_core && !opt_legacy) | ||
| g_printerr ("%swarning: In the future, the default compose mode will be --unified-mode. The legacy mode will be deprecated but available behind --legacy for some time. Use one of the two switches above to squash this warning.%s\n", get_bold_start (), get_bold_end ()); |
There was a problem hiding this comment.
We should probably throw a link in there with more details about the difference between the two.
|
We talked about this in person, just want to record things here. One thing I want to avoid is breaking the community of people using rpm-ostree with CentOS 7. We have landed various fixes in Fedora for unified core that aren't necessarily in C7 yet. We can probably get away with the fact that the rpm-ostree builds for CentOS7 aren't being updated, and tell anyone who wants to target C7 to use a C7 container on the source side too. Let's file an issue about this (copy the PR text mostly) and link to it like we do the I'd also say we add a Also before we do this we should submit a patch to https://pagure.io/pungi/ Big picture though I think you're right that we need to start this process, and deleting the old code is going to be great! |
|
Also I think a blocker here is verifying Silverblue builds in unified-core mode reliably. Last time I tried it I had to make a few fixes. |
OK, I split that into https://pagure.io/workstation-ostree-config/issue/137. Can you add some details there if you have them handy on some of the issues you hit? |
We still accept the `--unified-core` option, it just does nothing. We're talking about making 2019.2 the last release to support RHEL7. That makes it also a good cutover point to just drop the non-unified-core codepath. Since coreos-assembler defaults to it, we know it works. I also tested Silverblue with it. Alternative to coreos#1739
We still accept the `--unified-core` option, it just does nothing. We're talking about making 2019.2 the last release to support RHEL7. That makes it also a good cutover point to just drop the non-unified-core codepath. Since coreos-assembler defaults to it, we know it works. I also tested Silverblue with it. Alternative to coreos#1739
We still accept the `--unified-core` option, it just does nothing. We're talking about making 2019.2 the last release to support RHEL7. That makes it also a good cutover point to just drop the non-unified-core codepath. Since coreos-assembler defaults to it, we know it works. I also tested Silverblue with it. Alternative to coreos#1739
We still accept the `--unified-core` option, it just does nothing. We're talking about making 2019.2 the last release to support RHEL7. That makes it also a good cutover point to just drop the non-unified-core codepath. Since coreos-assembler defaults to it, we know it works. I also tested Silverblue with it. Alternative to coreos#1739
We still accept the `--unified-core` option, it just does nothing. We're talking about making 2019.2 the last release to support RHEL7. That makes it also a good cutover point to just drop the non-unified-core codepath. Since coreos-assembler defaults to it, we know it works. I also tested Silverblue with it. Alternative to coreos#1739
We still accept the `--unified-core` option, it just does nothing. We're talking about making 2019.2 the last release to support RHEL7. That makes it also a good cutover point to just drop the non-unified-core codepath. Since coreos-assembler defaults to it, we know it works. I also tested Silverblue with it. Alternative to coreos#1739
We still accept the `--unified-core` option, it just does nothing. We're talking about making 2019.2 the last release to support RHEL7. That makes it also a good cutover point to just drop the non-unified-core codepath. Since coreos-assembler defaults to it, we know it works. I also tested Silverblue with it. Alternative to coreos#1739
We still accept the `--unified-core` option, it just does nothing. We're talking about making 2019.2 the last release to support RHEL7. That makes it also a good cutover point to just drop the non-unified-core codepath. Since coreos-assembler defaults to it, we know it works. I also tested Silverblue with it. Alternative to coreos#1739
We still accept the `--unified-core` option, it just does nothing. We're talking about making 2019.2 the last release to support RHEL7. That makes it also a good cutover point to just drop the non-unified-core codepath. Since coreos-assembler defaults to it, we know it works. I also tested Silverblue with it. Alternative to coreos#1739
|
I think we should do #1793 instead - we already have the deprecation warning if they aren't specifying |
First, start printing the current mode we're operating in. This will
make it clear from the output if the default changes. Second, add a new
--legacyswitch that users can use today to explicit opt into thecurrent default. And third, start emitting a warning if neither
--legacynor--unified-coreis given.The way I'm thinking we can do this is (timespans flexible of course):
--legacyis given--legacy, gradually clean up code, and profit