Joel Sherrill commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1081#note_143586 Ignoring that the changes posted are too large as a single change as well as touch readme files that shouldn't be touched, I can only find https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4852 that mentions deprecating this function. The RTEMS Project has a deprecation [process](https://docs.rtems.org/docs/6.1/eng/coding-deprecating.html) that includes: * Announce deprecation in one major release (e.g 7.1) * Remove before the next major release (e.g. 8.1) * Both announcement and removal require issues targeting the appropriate release * Must be mentioned in the release notes (e.g. 7.1 and 8.1) * Documentation must be updated. This would be the Classic API Users Guide. There is a pattern for how deprecated methods are documented. See https://docs.rtems.org/docs/6.2/c-user/task/deprecated-directives.html * Marking to deprecated to show up in Doxygen (see https://docs.rtems.org/doxygen/branches/4.11/deprecated.html) This MR is jumping all the way to the end without following the process. At this point, you could just mark it deprecated and eliminate all uses. But the release notes, documentation, examples, and other repositories would need to be changed. As far as I can tell, you can only announce the deprecation now, document the deprecation, eliminate its use in RTEMS owned code, etc.. But you **CANNOT** remove the method yet because deprecation was never announced publicly. A comment in a corner of an odd file is not actionable for direct removal. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1081#note_143586 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
