The main problem with them is that due to an odd design decision they both share
the same configuration type -- RestRunConfigurationType, and it doesn't quite fit in
this newer typed API, e.g. isConfigurationFromContext() can receive a configuration
instance of a wrong type (DocutilsRunConfiguration for SphinxConfigurationProducer and
vice-versa) due to it, producing a CCE at runtime. I employed a workaround already
used in Python testing run configurations sharing the same problem. Namely,
overloaded getConfigurationSettingsList() to additionally check that instances of
RunnerAndConfigurationSettings with RestRunConfigurationType type actually
correspond to run configurations of the proper concrete class.
Note that setupConfigurationFromContext can also receive a run configuration of a wrong
type but in reality it doesn't happen since Sphinx and Docutils run configurations are
applied to different contexts -- directories and individual .rst files respectively.
GitOrigin-RevId: 15fbb90917edd68e6f29b696c527ff04d4eed433
Build scripts set proper values for bundled plugins and plugins for publishing.
Still, it's possible to break the logic if explicit since-build value is not match \d+.\d+ pattern or if until-build is omitted. So it's better to get rid of it at all.
They don't make any sense since
- they are not required for bundled plugins (com.intellij.ide.plugins.IdeaPluginDescriptorImpl#myVersion will be filled with IDE version)
- they will be overwritten during the build for pluginsToPublish (org.jetbrains.intellij.build.impl.DistributionJARsBuilder#setPluginVersionAndSince)
Still they may affect plugins loading mechanism, e.g. see https://youtrack.jetbrains.com/issue/GO-6741 or https://youtrack.jetbrains.com/issue/IDEA-188964