I also thought we had an official project policy for deprecating functions only after several major releases to avoid the scenario Brian describes.
tom > On Nov 15, 2016, at 12:20 PM, FREEMAN, BRIAN D <bf1...@att.com> wrote: > > It seems like you need at least one release for deprecation before removing a > function. I know I have code that uses the Config subsystem so it would be a > real pain to move in one release and creates an upgrade nightmare for me that > would slow down my migration to Carbon. > > Brian > > > From: controller-dev-boun...@lists.opendaylight.org > [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Colin > Dixon > Sent: Tuesday, November 15, 2016 12:14 PM > To: controller-dev > Subject: [controller-dev] deprecating the config subsystem in Carbon? > > During last week's Kernel projects call [0], I asked if and when we wanted to > deprecate the config subsystem. During the conversation, I think everyone > agreed that we should strongly discourage people from building new projects > based on it and encourage people to move toward Blueprint, which sounds like > the definition of deprecation. > > There was also seeming consensus that actually removing it in Carbon might be > a bad idea. Especially without a lot of effort. > > What are people's thoughts? > > Cheers, > --Colin > > [0] > https://meetings.opendaylight.org/opendaylight-meeting/2016/kernel_projects/opendaylight-meeting-kernel_projects.2016-11-08-17.05.html > > _______________________________________________ > controller-dev mailing list > controller-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/controller-dev
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
