When we did the first stable release of Beam (2.0.0) we decided to annotate most of the Beam IOs as @Experimental because we were cautious about not getting the APIs right in the first try. This was a really good decision because we could do serious improvements and refactorings to them in the first releases without the hassle of keeping backwards compatibility. However after some more releases users started to rely on features and supported versions, so we ended up in a situation where we could not change them arbitrarily without consequences to the final users.
So we started to deprecate some features and parts of the API without removing them, e.g. the introduction of HadoopFormatIO deprecated HadoopInputFormatIO, we deprecated methods of MongoDbIO and MqttIO to improve the APIs (in most cases with valid/improved replacements), and recently it was discussed to removal of support for older versions in KafkaIO. Keeping deprecated stuff in experimental APIs does not seem to make sense, but it is what he have started to do to be ‘user friendly’, but it is probably a good moment to define, what should be the clear path for removal and breaking changes of experimental features, some options: 1. Stay as we were, do not mark things as deprecated and remove them at will because this is the contract of @Experimental. 2. Deprecate stuff and remove it after n versions (where n could be 3 releases). 3. Deprecate stuff and remove it just after a new LTS is decided to ensure users who need these features may still have them for some time. I would like to know your opinions about this, or if you have other ideas. Notice that in discussion I refer only to @Experimental features.
