Re: [Discuss-gnuradio] Deprecation policy

[Ben Hilburn]

Great point, Laur! As Martin said, blocks do get moved into the "Deprecated" section as releases progress.

This problem is better addressed in things like GRC and PyBOMBS, but you're right that there is a gap when it comes to indicating deprecation for non-GRC examples distributed with GNU Radio.

Thanks for the suggestion!

Cheers,

Ben

On Fri, May 20, 2016 at 12:40 PM, Martin Braun <address@hidden> wrote:

Short answer: Yes, there is such a list.

Longer: We're still composing that. For GRC, we've already started
moving blocks to the deprecated section.

We'll definitely cull a lot of examples, too. If examples are using
deprecated stuff, we probably won't bother tagging them deprecated. For
modules/blocks, that's different and tagging them deprecated is the
right thing to do.

Cheers,
M

On 05/20/2016 02:27 AM, Laur Joost wrote:
> Hi!
>
> Is there a culling of examples planned for 3.8.0? The mailing list has
> an ever-increasing number of mails that consist of "Don't use that, it's
> old and bad, use this shinier one". For people who are not familiar
> enough to already know, this just looks like black magic, which is
> something that is always needed less of.
>
> An alternative would be a deprecation flag (or recommended versions) in
> basic_block, that could be modified, if a suggested replacement is
> introduced. That would then raise a warning at runtime, alerting early
> about potentially not future-proof design.
>
> While doxygen has a category for deprecated blocks, the sphinx
> documentation does not (leaving aside that for most blocks, if you want
> to do anything you need to refer to the doxygen anyway)
>
>

> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio