Hi Julian

Thanks for the hints I will look into it.


 On Tue, 10 Apr 2018 16:46:26 -0700
 Julian Hyde <jh...@apache.org> wrote:
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.


On Apr 10, 2018, at 7:18 AM, Animesh Trivedi <animesh.triv...@gmail.com> 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?


On Tue, Mar 13, 2018 at 9:57 PM, Julian Hyde <jh...@apache.org> wrote:


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.


On Tue, Mar 13, 2018 at 11:35 AM, Luciano Resende <luckbr1...@gmail.com>
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
building, staging, signing, etc):


On Tue, Mar 13, 2018 at 11:21 AM, bernard metzler <bmetz...@gmx.ch>

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

Is there anything else I am missing?

Thank you!

Luciano Resende

Reply via email to