Reviewing the repo at a particular commit is a good first step. The next step will be to create a release candidate (a tar ball and checksum files and signatures), add them to dist.apache.org for review, and send an email to start a vote.
Here is an example: https://lists.apache.org/thread.html/03b49fbed8617e860f71bc4f80abe411451d5f112beb5837cb9e5367@%3Cdev.calcite.apache.org%3E <https://lists.apache.org/thread.html/03b49fbed8617e860f71bc4f80abe411451d5f112beb5837cb9e5367@%3Cdev.calcite.apache.org%3E> I’d be careful with tags. It’s not good to change/delete tags applied to the master branch. So I wouldn’t apply the ‘v1.0’ tag until the release vote has passed. You could use ‘v1.0-rc1’ etc. for release candidates. I also strongly suggest that you compile a “howto” - a list of instructions that you followed to make the release, that can be followed by the next release manager next release - and commit it after the release. It is very important that the release process is consistent and reproducible. Julian > On Apr 10, 2018, at 7:18 AM, Animesh Trivedi <[email protected]> > wrote: > > Dear all, > > We are ready for our first source code release. We have tagged the current > candidate with v1.0 (https://github.com/apache/incubator-crail/tree/v1.0). > > What is the next step? Start a vote for "source-only" release where people > can review the currently tagged branch? > > Thanks, > -- > Animesh > > > On Tue, Mar 13, 2018 at 9:57 PM, Julian Hyde <[email protected]> wrote: > >> Bernard, >> >> You have it about right. >> >> One thing to remember is that a release is source-code only. (You may >> do binary releases later, but they are much more complicated.) >> >> Another is that releases don't need to be perfect in terms of >> functionality. It's fine if there are bugs, as long as the code >> compiles. The thing that trips up most podlings is getting the legal >> aspects right (e.g. no GPL-licensed dependencies, including necessary >> text in LICENSE and NOTICE files). >> >> I suggest you make a first release candidate, start a vote, and get >> feedback. The first couple of votes will likely fail. It will take a >> couple of iterations, but we don't expect perfection first time. >> >> When the PPMC vote passes, there is a second vote on the IPMC. (Due >> Apache policy that only a "real" PMC can make a release. The IPMC is >> real PMC, but the PPMC is only a PMC-in-training.) That second step is >> arduous I'm afraid (and adds a few extra days) but it's not too bad by >> the 2nd or 3rd release. >> >> Julian >> >> >> >> On Tue, Mar 13, 2018 at 11:35 AM, Luciano Resende <[email protected]> >> wrote: >>> I would say the most important thing would be to get the legal parts in a >>> good state. >>> >>> For guide, I would start with : >>> - http://www.apache.org/dev/#releases >>> >>> >>> For actual steps, here is what I have used in other projects (which >> include >>> building, staging, signing, etc): >>> >>> https://github.com/apache/bahir/blob/master/dev/release-build.sh >>> >>> >>> >>> On Tue, Mar 13, 2018 at 11:21 AM, bernard metzler <[email protected]> >> wrote: >>> >>>> Dear Mentors, >>>> >>>> Looks like we are getting close to a point where we think the code >>>> base is good for a first release. I just searched around a little >>>> to see what is needed from an administrative point of view. What >>>> I found is an overwhelming amount of information, starting >>>> at https://incubator.apache.org/guides/releasemanagement.html >>>> >>>> So, what I understand is, we have to follow some formal policies >>>> applicable to all ASF project releases >>>> (http://www.apache.org/legal/release-policy.html) plus setting up >>>> the code base in a staged area (which would be >>>> https://dist.apache.org/repos/dist/dev/incubator/crail/ - which >>>> does not yet exist?), and finally go through a PMC voting procedure, >>>> as described at >>>> https://incubator.apache.org/guides/releasemanagement.html >>>> >>>> >>>> Is there anything else I am missing? >>>> >>>> Thank you! >>>> Bernard. >>>> >>> >>> >>> >>> -- >>> Luciano Resende >>> http://twitter.com/lresende1975 >>> http://lresende.blogspot.com/ >>
