deprecations.rst 2.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657
  1. .. _deprecations:
  2. ================
  3. Deprecating Code
  4. ================
  5. Salt should remain backwards compatible, though sometimes, this backwards
  6. compatibility needs to be broken because a specific feature and/or solution is
  7. no longer necessary or required. At first one might think, let me change this
  8. code, it seems that it's not used anywhere else so it should be safe to remove.
  9. Then, once there's a new release, users complain about functionality which was
  10. removed and they where using it, etc. This should, at all costs, be avoided,
  11. and, in these cases, *that* specific code should be deprecated.
  12. In order to give users enough time to migrate from the old code behavior to the
  13. new behavior, the deprecation time frame should be carefully determined based
  14. on the significance and complexity of the changes required by the user.
  15. Salt feature releases are based on the Periodic Table. Any new features going
  16. into the develop branch will be named after the next element in the Periodic
  17. Table. For example, Beryllium was the feature release name of the develop
  18. branch before the 2015.8 branch was tagged. At that point in time, any new
  19. features going into the develop branch after 2015.8 was branched were part of
  20. the Boron feature release.
  21. A deprecation warning should be in place for at least two major releases before
  22. the deprecated code and its accompanying deprecation warning are removed. More
  23. time should be given for more complex changes. For example, if the current
  24. release under development is ``3001``, the deprecated code and associated
  25. warnings should remain in place and warn for at least ``Aluminum``.
  26. To help in this deprecation task, salt provides
  27. :func:`salt.utils.versions.warn_until <salt.utils.versions.warn_until>`. The
  28. idea behind this helper function is to show the deprecation warning to the user
  29. until salt reaches the provided version. Once that provided version is equaled
  30. :func:`salt.utils.versions.warn_until <salt.utils.versions.warn_until>` will
  31. raise a :py:exc:`RuntimeError` making salt stop its execution. This stoppage is
  32. unpleasant and will remind the developer that the deprecation limit has been
  33. reached and that the code can then be safely removed.
  34. Consider the following example:
  35. .. code-block:: python
  36. def some_function(bar=False, foo=None):
  37. if foo is not None:
  38. salt.utils.versions.warn_until(
  39. "Aluminum",
  40. "The 'foo' argument has been deprecated and its "
  41. "functionality removed, as such, its usage is no longer "
  42. "required.",
  43. )
  44. Development begins on the ``Aluminum`` release when the ``Magnesium`` branch is
  45. forked from the develop branch. Once this occurs, all uses of the
  46. ``warn_until`` function targeting ``Aluminum``, along with the code they are
  47. warning about should be removed from the code.