Ok, my question was also on the line: "is anyone ok in doing a release now" ? :)
> Instruction seems to be detailed. Though I will only be able to add > meaningful comment when I attempt these(volunteer for a release > manager) :) Sure, the wiki is a living document. Anyone should feel free to update and correct! > Slightly off topic question: Are we not using Jenkins for the build? Ideally we should try to move to Jenkins. The Java unit tests execution is much more reliable compared to Travis. There are few minor things to resolve for Jenkins, but the only major problem is how to compile C++. Now, we don't include the C++ build in our releases, but we should make sure everything compiles. I haven't found a way to install all the required dependency on Jenkins so that we can compile the C++ client. WIP Jenkins build: https://builds.apache.org/job/pulsar-master/ If anyone has time to look into it.. welcome ;) So my take is, for now use Travis, since it's already in place and working and move to Jenkins once the build is setup there. Matteo -- Matteo Merli <mme...@apache.org> On Mon, Jul 24, 2017 at 3:41 PM, Sahaya Andrews <andr...@apache.org> wrote: > Instruction seems to be detailed. Though I will only be able to add > meaningful comment when I attempt these(volunteer for a release > manager) :) > > Slightly off topic question: Are we not using Jenkins for the build? > > Andrews. > > On Mon, Jul 24, 2017 at 3:20 PM, Dave Fisher <dave2w...@comcast.net> > wrote: > > > >> On Jul 24, 2017, at 3:09 PM, Matteo Merli <mme...@apache.org> wrote: > >> > >> I have created a wiki page with the WIP instructions for the release > >> > >> https://github.com/apache/incubator-pulsar/wiki/Release-process > >> > >> I also have created an INFRA ticket to create the Nexus project so that > we > >> can publish maven artifacts. > >> https://issues.apache.org/jira/browse/INFRA-14694 > >> > >> > >> Any comments on the questions asked? > > > > In item #3 of the release process two additional checks are needed to > help with voting. > > > > (a) The output for the RAT report needs to be examined to make sure that > all of the source has the proper headers. That any excluded files are > properly explained. > > (b) The two release artifacts need to have hashes generated so that > users can be sure that they downloaded the genuine package. I believe that > MD5 and SHA256 are now typical ... > > > >> > >> If there are no concerns/objections I could volunteer to be the release > >> manager for this release and then we could start a rotation across the > >> committers for the subsequent releases. > > > > Rotation and a well documented build release process is excellent > practice. > > > > Regards, > > Dave > > > >> > >> Matteo > >> > >> -- > >> Matteo Merli > >> <mme...@apache.org> > >> > >> On Fri, Jul 21, 2017 at 4:23 PM, Matteo Merli <mme...@apache.org> > wrote: > >> > >>> (Starting a new thread to detach from the general website discussion) > >>> > >>> I think that it would be good to try to release a new Pulsar version > ASAP, > >>> following the Apache release process and requirements. > >>> > >>> That would take the project out of the current limbo where we are in > the > >>> incubator, but we can only point users to Yahoo releases of Pulsar. > >>> > >>> Once the 1st Apache release is ready, it would be easier to create new > >>> releases, since most of comments and feedback from the IPMC are > related to > >>> release process and content of the artifacts. Once we establish that, > the > >>> rest will be downhill. > >>> > >>> Questions: > >>> > >>> * Release Manager > >>> Does for podlings work in the same way as for TLPs? Should we design > a > >>> release manager? > >>> > >>> * Pending changes > >>> What are the pending changes that *absolutely* need to go in > >>> 1.19-incubating release? > >>> > >>> * Versioning number > >>> Since we're going from "pulsar" to "apache-pulsar" artifacts, as Dave > >>> suggested it could be the right moment to change versions. The options > I > >>> see are : > >>> > >>> - 1.19-incubating This is keeping the continuity in versioning and > >>> also signals that no major changes have been introduced. > >>> - 2.0-incubating I think should be reserved for breaking changes > >>> - 1.0-incubating I wouldn't go back in time > >>> > >>> Any suggestions? > >>> > >>> Open items: > >>> * Formalize the release procedure > >>> It should be documented in the Wiki so that each committer should be > >>> able to perform a release. > >>> > >>> For all committers, please go through these documents to familiarize > with > >>> the process, and provide feedback on the Pulsar release instruction > wiki: > >>> > >>> - https://incubator.apache.org/guides/releasemanagement.html > >>> - http://www.apache.org/legal/release-policy.html > >>> - http://www.apache.org/dev/release-distribution.html > >>> - http://www.apache.org/dev/release-publishing.html > >>> - http://www.apache.org/dev/publishing-maven-artifacts.html > >>> > >>> > >>> Matteo > >>> > >>> -- > >>> Matteo Merli > >>> <mme...@apache.org> > >>> > > >