jcamachor commented on code in PR #434: URL: https://github.com/apache/incubator-xtable/pull/434#discussion_r1668183451
########## release/release_guide.md: ########## @@ -0,0 +1,570 @@ +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> + +# Introduction + +Apache XTable, currently an incubating project at the Apache Software Foundation (ASF), is a cross-table converter for table formats that facilitates omni-directional interoperability across data processing systems and query engines. +This guide outlines the steps for releasing Apache XTable versions, following the ASF policies and incorporating practices from other successful ASF projects. + +# Legal Reminders + +Releasing software under the ASF banner requires adherence to the [ASF Release Policy](https://infra.apache.org/release-publishing.html) and [Incubator Release Guidelines](https://incubator.apache.org/guides/releasemanagement.html#best-practice). +Please ensure all releases comply with these guidelines, focusing on proper licensing, source code distribution, and community approval. + +# Overview + + + +The release process consists of several steps: + +1. Decide to release +2. Prepare for the release +3. Build a release candidate +4. Vote on the release candidate +5. During vote process, run validation tests +6. If necessary, fix any issues and go back to step 3. +7. Finalize the release +8. Promote the release + +# Decide to release + +Deciding to release and selecting a Release Manager is the first step of the release process. This is a consensus-based +decision of the entire community. + +Anybody can propose a release on the dev@ mailing list, giving a solid argument and nominating a committer as the +Release Manager (including themselves). There’s no formal process, no vote requirements, and no timing requirements. Any +objections should be resolved by consensus before starting the release. + +In general, the community prefers to have a rotating set of 3-5 Release Managers. Keeping a small core set of managers +allows enough people to build expertise in this area and improve processes over time, without Release Managers needing +to re-learn the processes for each release. That said, if you are a committer interested in serving the community in +this way, please reach out to the community on the dev@ mailing list. + +## Checklist to proceed to the next step + +1. Community agrees to release +2. Community selects a Release Manager + +# Prepare for the release + +Before your first release, you should perform one-time configuration steps. This will set up your security keys for +signing the release and access to various release repositories. + +To prepare for each release, you should audit the project status in the JIRA issue tracker, and do the necessary Review Comment: Potentially! Should we establish a mechanism that we can document in the release guide and we can reuse in future releases, e.g., creating a GitHub label to tag these issues (blockers)? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
