- Determine public vs. private API surface in order to get a clear picture on what code elements can be renamed without triggering a breaking change and therefore a major release (if using semantic versioning)
- Update source code references
- Classes
- Interfaces
- Imports
- Do keep in mind that these have to be separated based on internal vs. published API elements
- Update source code references
- Update links pointing to the GitHub repository within
- source code
- documentation that's managed separately from the source code (if applicable)
- Double check that your GitHub apps still work after the repository rename.
- Some GitHub app configurations might have hard-coded repository names/URLs stored in their configuration.
- ReadTheDocs page (if applicable)
- Calendar meetings (where applicable)
- Note: The calendar is tied to the mailing list meaning that once the brand new mailing list has been created the maintainers will have to manually recreate all the regular calendar entries.
- Wiki pages (Hyperledger staff/project maintainers)
- Package managers/published artifacts (where applicable)
- npm
- Maven/Gradle
- Container images
- Plan ahead with communication to your users who depend on your project artifacts. Make sure they are aware that a completely new artifact name will be used in the future and therefore they have to update their own source code/dependency declaration files (such as package.json, build.gradle, pom.xml, etc.)
- Slide decks (if applicable)
- Whitepapers (if applicable)
- GitHub Integrations (where applicable):
- ZenHub
- MergeFreeze
- Jira
- Gitter
- GitGuardian
- etc.
- We're done
...