+1 for bullet 1 assuming new code implies brand new classes (since it doesn't involve any backward compatibility issues). We can always review contributor PRs to make sure new code is added with new package naming guidelines.
But for 2 and 3 I have a question/comment: is there even a need to do it? There is lots of open source code with package names like com.google.* and com.sun.* etc and as far as I know there are no moves afoot to rename these packages. The renaming itself doesn't add any new functionality or technical capabilities but introduces instability in Apex code as well as user code. Just a thought... On Mon, Feb 27, 2017 at 8:23 AM, Chinmay Kolhatkar <chin...@datatorrent.com> wrote: > 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 > > >
