This document is considered complete, and may be revised at a later point.
What goes into a release
A podling should begin to familiarize itself with ASF policies for releases. Those policies can be found at http://www.apache.org/dev/#releases.
It is well understood that one of the goals of incubation is to help a podling understand how to build ASF compliant releases. This is why its mandatory to have at least 3 +1 votes from IPMC members review the releases (this should include your mentors but is not mandatory) for accuracy in compliance with the ASF and Incubator policies. The podling community, of course, needs to be fully engaged in review process as well. Anybody reviewing the releases will provide the release manager and IPMC members with information about what is wrong with the release. The severity of the issues and whether they are blocking or not may be discussed but the ultimate guidance on where podling releases may get additional flexibility belongs to the mentors and IPMC members.
The Incubator policies apply two additional constraints to podlings for their releases. They are repeated here for clarity only.
- Release artifacts must include incubating in the final file name
- Release artifacts must include a disclaimer within the release artifact(s) as noted
In order for a podling to receive full permission from the IPMC to execute the release, the release vote must be held on the incubator general list and pass based on the standard Package Release voting rules. Only Incubator PMC votes are binding, but all are encouraged to vote.
Java Specific Best Practices
The incubator has put together a number of best practices for java based projects which can be found at Java-specific Release Management Issues
Eclipse Update Sites
Podlings may create Eclipse Update Sites to publish artifacts that are consumed as Eclipse Plugins. For details, please review Releasing Eclipse Update Sites