From Fedora Project Wiki

No edit summary
No edit summary
Line 9: Line 9:
== After the review ==
== After the review ==


After the review is completed, and is satisfactory (for the avoidance of doubt, the lack of a clean upgrade path for users of the package in the form of proper Provides and Obsoletes is considered a blocker to the review), request CVS for the package as you normally would for a new package.
After the review is completed, and is satisfactory (for the avoidance of doubt, the lack of a clean upgrade path for users of the package in the form of proper Provides and Obsoletes is considered a blocker to the review), request git for the package as you normally would for a new package.


After the new package is imported into CVS, you can then follow the [[How to remove a package at end of life|package retirement process]] for the old package.
After the new package is imported into git, you can then follow the [[How to remove a package at end of life|package retirement process]] for the old package.


[[Category:Package Maintainers]] [[Category:Guidelines hackfest]] [[Category:Policy]]
[[Category:Package Maintainers]] [[Category:Guidelines hackfest]] [[Category:Policy]]

Revision as of 05:13, 3 August 2010

For a variety of reasons it may become necessary to rename a package in Fedora. The goal of this page is to outline the process that must be followed when such an event occurs.

Re-review required

When you wish to rename a package, you MUST request a re-review of your package through the normal review process. In this review request, you MUST state that this is a re-review request for a package rename, and the old package name that this is replacing.

The reviewer of the package MUST explicitly acknowledge this fact, and check the package for the proper Obsoletes and Provides (see the naming guidelines for more information.) They MUST document in the review request that they have done so.

After the review

After the review is completed, and is satisfactory (for the avoidance of doubt, the lack of a clean upgrade path for users of the package in the form of proper Provides and Obsoletes is considered a blocker to the review), request git for the package as you normally would for a new package.

After the new package is imported into git, you can then follow the package retirement process for the old package.