So, even though the file is in src/ it imports a generated file, see here: https://github.com/opendaylight/lacp/blob/master/lacp-main/implementation/src/main/java/org/opendaylight/yang/gen/v1/urn/opendaylight/lacp/lacp/main/rev141216/LacpMainModule.java#L35
You could thus deprecate the generated class: in this case org.opendaylight.yang.gen.v1.urn.opendaylight.lacp.lacp.main.rev141216.AbstractLacpMainModule That would work with a relatively simple change in the code generator and apply everywhere, right? --Colin On Wed, Nov 16, 2016 at 7:11 PM, Ryan Goulding <ryandgould...@gmail.com> wrote: > You mean the Provider? Most people adapt the Provider and put it in src/ > anyway; I would guess this wouldn't really raise much awareness but that > is my own $0.02. The easiest path forward is probably to make sweeping > announcements via email and strong suggestions in the release notes... but > I could be wrong. Open to discussion on the strategy going forward. Tom > Pantelis may have a clever suggestion for this too... > > Regards, > > Ryan Goulding > > On Wed, Nov 16, 2016 at 2:50 PM, Colin Dixon <co...@colindixon.com> wrote: > >> 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 >> >> >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
