On 8/28/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Niklas Therning wrote:
<snip>
> Binaries and other releases should definitely be at the ASF. I'm sorry > for the 0.2 release. It was a quick fix and I didn't have the time at > the moment to look into how to move things to the ASF. But now when this > is going to happen please enlighten me on how things work. Where do new > releases go? How to make them? Who can do new releases? We need to be > able to release mime4j as a separate component. The procedure is: - tag the content you want to release - create the package for the release - start a vote - if the vote is succesfully, publish the release.
that's pretty much the minimal formal process: a successful binding vote means that the packaged release is an official apache release. however, the release needs also to comply with the appropriate ASF policy (more on that a little later). in practice, most projects adopt more ceremony than that: for example, it's useful to have a release manager to stear the release through who's traditionally elected by lazy consensus. it is usual for more mature components with large user bases to use more elaborate processes using (for example) multiple release candidates, beta and so on. probably not necessary in this case. policy is simple but subtle (its rare for components to create compliant releases at the first attempt). openPGP compliant signatures and MD5 checksum must be created for each artifact. the legal paperwork much be in place (including appropriate license headers in all source files - that includes configuration and build files). correct LICENSE and NOTICE must ship in each artifact (any jars that may find their way onto the maven repositories should contain NOTICE and LICENSE files in their META-INF directories). http://www.apache.org/dev is the apache developmer documentation. for more information, follow the links. - robert
