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:
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
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
We are ready for our first source code release. We have tagged the
candidate with v1.0
What is the next step? Start a vote for "source-only" release where
can review the currently tagged branch?
On Tue, Mar 13, 2018 at 9:57 PM, Julian Hyde <jh...@apache.org>
You have it about right.
One thing to remember is that a release is source-code only. (You
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
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
arduous I'm afraid (and adds a few extra days) but it's not too bad
the 2nd or 3rd release.
On Tue, Mar 13, 2018 at 11:35 AM, Luciano Resende
I would say the most important thing would be to get the legal parts
For guide, I would start with :
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>
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
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?