Thomas, I agree with you that we need this migration to be done but I have a different opinion on how to execute this. I think if we do this in phases as described above, users might end up in more confusion.
For doing this migration, I think it should follow these steps: 1. Whether for operator library or core components, we should announce widely on dev and users mailing list that "...such change is going to happen in next release" 2 Take up the work all at once and not phase it. Thanks, Chinmay. On Mon, Feb 27, 2017 at 9:09 PM, Thomas Weise <t...@apache.org> wrote: > Hi, > > This topic has come up on several PRs and I think it warrants a broader > discussion. > > At the time of incubation, the decision was to defer change of Java > packages from com.datatorrent to org.apache.apex till next major release to > ensure backward compatibility for users. > > Unfortunately that has lead to some confusion, as contributors continue to > add new code under legacy packages. > > It is also a wider issue that examples for using Apex continue to refer to > com.datatorrent packages, nearly one year after graduation. More and more > user code is being built on top of something that needs to change, the can > is being kicked down the road and users will face more changes later. > > I would like to propose the following: > > 1. All new code has to be submitted under org.apache.apex packages > > 2. Not all code is under backward compatibility restriction and in those > cases we can rename the packages right away. Examples: buffer server, > engine, demos/examples, benchmarks > > 3. Discuss when the core API and operators can be changed. For operators we > have a bit more freedom to do changes before a major release as most of > them are marked @Evolving and users have the ability to continue using > prior version of Malhar with newer engine due to engine backward > compatibility guarantee. > > Thanks, > Thomas >
