I'm a little late, but +1 on the plan for a 0.14.0 release followed by 1.0.0
On Sun, Jun 16, 2019 at 5:45 AM Wes McKinney <wesmck...@gmail.com> wrote: > I also agree that time-based releases are the only reasonable thing to > do going forward. It also creates a sense of urgency to complete work > by a certain date, in the sense of "the ship is leaving the port on X, > all aboard!" > > The Blocker priority on JIRA can be used to communicate if some issue > should prevent a release candidate from being cut, but contributors > can also state whether there is some concerning issue here on the > mailing list. > > With that being said, I think we should have the backlog closed and > the project ready by June 24. A number of optional builds are still > broken, and Flight is not set up in the Python packages, so those are > the things that I would like to see sorted out by then, all the rest > is nice-to-have. > > - Wes > > On Sun, Jun 16, 2019 at 3:38 AM Sutou Kouhei <k...@clear-code.com> wrote: > > > > Hi, > > > > > If we want to stick to project-wide releases where all languages and > > > components are released once, then time-based releases are the only > > > reasonable scheme IMHO. Of course, there may still be release-blocking > > > issues, but those should only be important regressions, not "this is a > > > feature we'd definitely like to see in this release". > > > > I think so too. > > > > I'll make blocker tasks "nice-to-have" if these tasks aren't > > critical for release. For example, I'll mark them > > "nice-to-have" as a release manager if they doesn't fix not > > buildable issues. > > > > In pre-release, the followings are helpful: > > > > * JIRA tidying > > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-JIRAtidying > > > > * Testing API document generation > > How? Documented? > > > > * Testing package builds and generated packages > > * For package builds: Crossbow is used. Where is the document? > > * For package test: How? Documented? > > > > * Testing the master on many platforms > > > > In release process, the followings are helpful: > > > > * Resolving issues reported by release manager > > > > * Testing RC > > > > In post-release, the followings are helpful. Some of them > > requires PMC member or committer role but others can be worked > > by everyone: > > > > * Updating the Arrow website > > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingtheArrowwebsite > > * Require committer role > > > > * Announcing release > > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Announcingrelease > > * Require PMC member role? > > > > * Updating website with new API documentation > > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingwebsitewithnewAPIdocumentation > > * Require committer role > > > > * Updating C++ and Python packages > > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingC++andPythonpackages > > * Everyone can work on? > > > > * Updating Homebrew packages > > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingHomebrewpackages > > * Everyone can work on > > > > * Updating Ruby packages > > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingRubypackages > > * Require PMC member role? > > > > * Updating JavaScript packages > > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingJavaScriptpackages > > * Require PMC member role? > > > > * Updating .NET NuGet packages > > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Updating.NETNuGetpackages > > * Require PMC member role? > > > > * Updating Rust packages > > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingRustpackages > > * Require PMC member role? > > > > * Updating CRAN packages > > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingCRANpackages > > * Require PMC member role? > > > > > > Thanks, > > -- > > kou > > > > In <20190615114806.1a23be13@fsol> > > "Re: [DISCUSS] Timing of release and making a 1.0.0 release marking > Arrow protocol stability" on Sat, 15 Jun 2019 11:48:06 +0200, > > Antoine Pitrou <solip...@pitrou.net> wrote: > > > > > On Fri, 14 Jun 2019 16:41:47 -0700 > > > Neal Richardson <neal.p.richard...@gmail.com> wrote: > > >> > > >> I gather that this has all been done informally in the past, but > would some > > >> folks be interested in taking up this release-prep role for the > various > > >> languages and formalizing that responsibility a bit? By "formalize" I > just > > >> mean write down on the wiki ( > > >> > https://cwiki.apache.org/confluence/display/ARROW/Arrow+0.14.0+Release) > who > > >> is overseeing the release for each language and what the current > status is. > > >> That way, Kou and anyone else can see at a glance which subprojects > are > > >> ready for release and who to talk to about wrangling the others. For > my > > >> part, I've been curating the R backlog and 0.14 release scope and > working > > >> with Romain and others to get the essentials done, and I'd be happy to > > >> record that I'm doing this and publicize when the key issues have been > > >> addressed and we're ready to release. If different people were to do > that > > >> for the other 10 languages, we could eliminate some ambiguity as to > what > > >> the status is and who is taking responsibility for ensuring that the > > >> necessary work gets done. > > > > > > The risk if we have that kind of process for 11 languages is that > > > releases never get ready because there's always something left to > > > improve, fix or clean up. > > > > > > If we want to stick to project-wide releases where all languages and > > > components are released once, then time-based releases are the only > > > reasonable scheme IMHO. Of course, there may still be release-blocking > > > issues, but those should only be important regressions, not "this is a > > > feature we'd definitely like to see in this release". > > > > > > Regards > > > > > > Antoine. > > > > > > >
