Thorsten Scherler wrote: > > IMO A should be the way to wrap up current development. Like pointed > out by David we need to have a release that contains the work of the > last years since the release.
It may require two releases in reasonably quick succession. Otherwise we risk holding up the release for more ages. > To be honest I have not tackle the release because seeing the process > I feel overwhelmed of the steps involved. I saw other project > releasing their software in a more straight forward manner. Do those projects also add their current documentation as an integrated part of their release package, and provide the means to generate that same version of the documentation? This adds some complexity to Forrest's release process. There are a number of Catch-22 situations and extra hoops. The release process doc is reminders for me when/if i was the RM. I wrote down every little step so that it could be remembered from time-to-time and flow smoothly. The last release was much easier with those notes. It also intends to enable other people to assist with certain parts of the process, so the whole thing is explicitly defined. Many thanks to those people that helped to evolve it. Any committer is free to be RM and to create their own release process, and to propose different content for the release. -David
