You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@crail.apache.org by bernard metzler <bm...@gmx.ch> on 2018/03/13 18:21:57 UTC
preparing for a first release
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.
Re: preparing for a first release
Posted by Jonas Pfefferle <pe...@japf.ch>.
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
>><an...@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
>>><lu...@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 <bm...@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/
>>>
>
Re: preparing for a first release
Posted by Julian Hyde <jh...@apache.org>.
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 <an...@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 <lu...@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 <bm...@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/
>>
Re: preparing for a first release
Posted by Animesh Trivedi <an...@gmail.com>.
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 <lu...@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 <bm...@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/
>
Re: preparing for a first release
Posted by Julian Hyde <jh...@apache.org>.
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 <lu...@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 <bm...@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/
Re: preparing for a first release
Posted by Luciano Resende <lu...@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 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 <bm...@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/