From rPath Wiki

Release Management Process

Draft

We've been using a process like this for managing our own work internally, especially for maintenance branches. It has worked well for us, and we want to start using it more widely for managing our repository, and also make it available as a pattern for managing other projects in other repositories.

1. For significant changes, please open an issue in Jira. If you aren't sure if it is significant, it probably is. Feel free to ask.
   1. Your changes should follow the rules
2. Create a sandbox for testing your fix: cvc shadow yourrepository.rpath.org@rpl:devel-test affectedtrove:source=conary.rpath.com@rpl:devel
   1. Change rpl:devel to rpl:1 or rpl:2 or whatever as appropriate; be aware that maintained branches take limited changes.
   2. If you are building a great many packages, you may want a unique shadow reserved for only this work, perhaps conary.rpath.com@rpl:devel//yourrepository.rpath.org@rpl:devel-test-feature and in order to test everything together, you may need also to shadow group-dist and modify it in order to test the effects. Any time you need to test building a new group, you will want a unique shadow.
   3. For testing only one modified package that will not affect group structure, there is no need for a feature-specific shadow.
3. Commit the fix to the shadowed source trove, mentioning the Jira issue ID in the commit message.
4. Build your package with rMake on at least one architecture, test, fix until your modified package or packages work. Commit at least your final package build for inspection.
5. When your fix is ready to integrate, annotate the fixed version(s) in the Jira issue you created.