add optional support for xdg_config|cache_dir by jrabinow · Pull Request #13224 · ipython/ipython
This PR adds support for xdg_config_dir and xdg_cache_dir on all posix systems. All behavior should be identical except when ipython files exist in xdg_config_dir and not in $HOME, they won't be ignored or moved.
jrabinow
changed the title
add optional support for xdg_config|cache_dir
add optional support for xdg_config|cache_dir on OS X
jrabinow
changed the title
add optional support for xdg_config|cache_dir on OS X
add optional support for xdg_config|cache_dir
@Carreau could I ask why this PR needs to wait till 8.0 for release? This PR is purely adding functionality in a 100% backwards-compatible way - are there any testing issues, other changes in the works that this interferes with, or a strict release policy that prevents anything other than existing featureset maintenance for minor releases?
I'm not objecting to waiting till 8.0 to merge this in, but I'd like to understand why, even if it's due to lack of bandwidth, which is totally understandable.
Apologies for the delay in reviewing the last weeks, and next few ones are going to be busy. I'll do my best to review soon.
@Carreau could I ask why this PR needs to wait till 8.0 for release? This PR is purely adding functionality in a 100% backwards-compatible way - are there any testing issues, other changes in the works that this interferes with, or a strict release policy that prevents anything other than existing featureset maintenance for minor releases?
I'm not objecting to waiting till 8.0 to merge this in, but I'd like to understand why, even if it's due to lack of bandwidth, which is totally understandable.
I try to minimize backport of functionalities to 7.x unless asked to do so. There is bandwith, but there is also pushing users to migrate to 8.0 once this gets out.
No worries about the review, I totally understand :-)
I try to minimize backport of functionalities to 7.x unless asked to do so. There is bandwith, but there is also pushing users to migrate to 8.0 once this gets out.
My concern is that after the upcoming 7.30 release, there might be a 7.3[1-9] and so on... releases. Meanwhile the 8.0 doesn't have a due date. I'm worried that waiting for 8.0 means that this change will be stuck in limbo for a year or 2, which I'd like to avoid.
On the other hand, I don't want to put an undue burden on the ipython dev team. Would it make sense to leave this as 8.0 milestone, but if no release date has been determined within 6 months, or if in a years time 8.0 release looks as close as it does today, we can flag this change for backporting at that time?
We got funding to get rid of nose mid October, see #13108 we should be a pinned issue. Once this is done I'd likely do a couple passes on marking things as deprecated and want to do a 8.0 beta at earlier end of year. But yes I hear you, I originally thought 8.0 would be early 2021.
…On Sun, Nov 7, 2021, 18:40 jrabinow ***@***.***> wrote: No worries about the review, I totally understand :-) I try to minimize backport of functionalities to 7.x unless asked to do so. There is bandwith, but there is also pushing users to migrate to 8.0 once this gets out. My concern is that after the upcoming 7.30 release, there might be a 7.3[1-9] and so on... releases. Meanwhile the 8.0 doesn't have a due date. I'm worried that waiting for 8.0 means that this change will be stuck in limbo for a year or 2, which I'd like to avoid. On the other hand, I don't want to put an undue burden on the ipython dev team. Would it make sense to leave this as 8.0 milestone, but if no release date has been determined within 6 months, or if in a years time 8.0 release looks as close as it does today, we can flag this change for backporting at that time? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13224 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACR5T5JOUI5XTZBS3PRHD3UK42CDANCNFSM5G4IM2DQ> .
Ah, so according to #13108 8.0 is expected for late December/early January 2022… no more concerns from me. Thanks for the link, and good luck with the migration!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters