Hi Bookies, I was going through the issues and the code and noticed there were a few 'clean up' issues which have been there since some time and I was wondering what's the community's opinion on them. Often we have upstream consumers who use certain versions and depend on certain APIs provided in those versions so it's best to socialize this issue with everyone to know what's the best way forward.
- *Moving the codahale and other loggers into their own packages.* *Issue(s) link:* https://github.com/apache/bookkeeper/issues/1262 https://github.com/apache/bookkeeper/issues/762 * State: * The files were moved into their own packages and the original classes were marked as @Deprecated in 2018 commit -> https://github.com/apache/bookkeeper/commit/fc8097f33242d6b1a6cbcce10466fb5bfc663b5a We have had a couple of releases after that (4.7.0 to 4.11.1) *Question to community:* Shall we go ahead and remove the original Codahale*.java now that they've been put in their own packages for multiple releases? - *zkServers vs metadataServiceURI **Issue link:* https://github.com/apache/bookkeeper/issues/1920 *State:* We use config parameters zkServers and metadataServiceURI which both serve the same purpose. We chose to deprecate zkServers and go with metadataServiceURI. zkServers was deprecated in 2018 commit -> https://github.com/apache/bookkeeper/commit/3d39435d316bc05e64c4247aeb8455bcd2a96989 We have had a couple of releases after that (4.8.0 to 4.11.1) *Question to community:* Is it a good time to remove all references of 'zkServers' and related code now that we've had enough 'soak time'? - *CLIENT_TLS_KEYSTORE_TYPE -> TLS_KEYSTORE_TYPE* *Issue link:* No Issue created for this. *State:* Since the 2018 commit -> https://github.com/apache/bookkeeper/commit/76c1fd0d8ad1358fc8799d66b6ec7f242fd2ba71 We have reconfigured to use *TLS_KEYSTORE_TYPE* internally since 4.7.0 release. *Question to community:* Is it OK to retire CLIENT_TLS_* config values now? *Ending thoughts and my opinion:* Cleaning up code is always difficult as it might break something for someone using older versions. My thought is to start cleaning up with the least impacting / used @Deprecated code and move up. For the high use functionalities which are mentioned above we all have to agree on a path forward. Regards, Anup -- Anup Ghatage www.ghatage.com
