Hi Julian
Thanks for the hints I will look into it.
Jonas
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.
Julian
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?
Thanks,
--
Animesh
On Tue, Mar 13, 2018 at 9:57 PM, Julian Hyde <jh...@apache.org>
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
<luckbr1...@gmail.com>
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 <bmetz...@gmx.ch>
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/
