That sounds good to me. What's the right way for us to "deprecate" the config subsystem. I guess the simplest thing would be add an @deprecated decorator to the relevant classes that get generated with a pointer to the docs on how to migrate.
--Colin On Tue, Nov 15, 2016 at 5:07 PM, FREEMAN, BRIAN D <bf1...@att.com> wrote: > I think Option 2 is a reasonable approach. > > Brian > > > -----Original Message----- > From: controller-dev-boun...@lists.opendaylight.org [mailto: > controller-dev-boun...@lists.opendaylight.org] On Behalf Of Robert Varga > Sent: Tuesday, November 15, 2016 4:46 PM > To: Alexis de Talhouët; thomas nadeau > Cc: controller-dev > Subject: Re: [controller-dev] deprecating the config subsystem in Carbon? > > On 11/15/2016 10:08 PM, Alexis de Talhouët wrote: > > > > Option 2: > > Deprecation notice in Carbon > > Adaptation in Nitrogen > > Removal in Oxygen > > > > During the kernel meeting I was more after option 3, but I think option > > 2 make sense so downstream consumer can be notified earlier in the > > process and start migrating things to blueprint. > > I think option 2 works best, especially since we can decide on when the > actual removal takes place -- which I think should be one release after > we have shipped without internal projects using it. > > Bye, > Robert > > _______________________________________________ > 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
