Hi, > They said we could label the website version as a "development version" or > "snapshot" (like Maven) does. I'm really not sure we want to do that (see below).
> I don't see any reason to add process where process is not required It's about community building. > we can save time by not having to through the release process to fix bugs > in the website version of TDF Can you spell out the process here. As I see it - benefits of using a voting process: - PMC endorsement - Legal angle covered (IP issues etc) - Community engagement (testing RCs + finding / fixing bugs + responding to release announcement) - Voting process is relatively simple and straight forward - Testing RCs and being involved in process == more "points" towards committership * - RC process encourages people to find and report issues - Hopefully potential people to consider for commitership - Hopefully encourage a person to step forward and be a release manger - Clear idea of changes between versions (via release notes) - Can announce on apache lists and in blogs - we can't announce snapshots (basically nightly builds) that way - Not in "under construction" / "development use only" mode continually. Different quality perception. Note that apache blog announcements can get several thousand views and gives good visibility of Apache Flex in the wider Apache community. The Tour De Flex announcement yesterday got 1300+ views. Only down side I see is that we can't make changes very quickly (ie a few hours or days). But how quickly do we fix errors that arise anyway? There's JIRA's about broken examples that have been open for a few days but no one rushed in to fix them yet I see. ;-) If we make changes directly on web site: - Gives an expectation that issues will be fixed quickly - can we actually do that? - IP or other legal issues may arise if all checkin /patches are not carefully monitored - Less reason for community to be involved (no RCs to test or vote on) - No need for a release manager or in fact any further releases - Pages on web site / artefacts in dist will become out of date and not match site - JIRAs may become confused as we may not have version numbers (what's the version number of a nightly build?) - Can't announce on apache lists and in blogs = less apache exposure and less social media engagement How about let's see if we can make a release or two under the existing RC candidates / voting system and if that process causes any issues revisit it? Thanks, Justin
