I’d like to deprecate a field in export, with the intent of removing it later, specifically,

test_platform

. I could add a deprecate conditional call in export, but I’m not sure if that’s the right approach, because it might be noisy. Alternatively, we could just leave it in until there’s more needed changes to export, and remove it as part of doing that.

Generally, we’ve been the past two months deprecating things in small chunks like this. There has been and will continue to be a lot of churn as we migrate things to V2. We’re trying to make it a little more incremental for people so that it’s easier for them to upgrade and to avoid a Python 2 vs. Python 3 community split So, without knowing much context, I’d bias towards deprecating now

I think my question is more about mechanics. I’m replacing

test_platform

with

runtime_platform

. The export json has a versioning scheme where additive changes bump the patch level, and removals bump the minor level. I’d like to remove

test_platform

from the export json, but I think it should go through a deprecation cycle. I don’t know though, whether having a deprecation warning about test_platform for each export invoke is worth it, or if it should just be noted in the code.

@wide-energy-11069: ^

afaict intellij pants plugin is not using ‘test_platform’: https://github.com/pantsbuild/intellij-pants-plugin/search?utf8=%E2%9C%93&q=test_platform&type=

@wide-energy-11069 Should I just add comments next to the old field inserts, or a deprecate_conditional? I’m leaning towards comments because I don’t know what version we’d want to do the minor export bump at.

comments would be fine yeah.

👍

right now it’s 1.0.14, so deprecation would make it 1.0.15. removal would be 1.1.0