On Thu, Dec 13, 2018 at 11:29 AM Joe Francis <j...@oath.com.invalid> wrote:
> -1. > > The amount of changes this will need, especially around tools and code > developed around the old API is enormous. > > And no, remaining with the old lib is not an option, unless there is a plan > to maintain the old lib, with dependencies up-to-date with security fixes > Marking the Pulsar 2.x vs 1.x was mainly around these "breaking" changes. To ease the upgrade path, we made sure to not break compatibility but rather just mark deprecation on the old methods. If it's important to keep Pulsar 1.x APIs around, I would rather keep a separate module `pulsar-client-1x` that will use the old API and that will be just based on the regular `pulsar-client` library. Applications that don't want to switch API will just have to switch maven artifact. > I would like the team to discuss and publish a clear plan around LTS for > Pulsar, not only just the API, but also BK. > Agree on that, it would be good to have a formal statement of what is the policy. In particular, many new users are not aware that we always keep a working live upgrade/rollback policy for all releases (included 1.22 to 2.0). Having that stated clearly would be very helpful.
