Yep! Kengo and I agreed to not worry about the prior release information for the 0.2.1 release and he's going to file a follow-on jira for us to copy all of the release info from master (without maintaining specific commits) as a part of our release process in the future.
After that, he changed his vote to +1. Later I voted +1 and yesterday evening Allen did as well. The vote has now closed, with just enough votes to pass. I'm not sure where Kengo is on 0.3.0 RCs. Kengo, could you start a new thread that summarizes what we still need to do for that release? On Thu, Apr 7, 2016 at 3:49 PM, Chris Nauroth <[email protected]> wrote: > Sean and Kengo, did the two of you reach agreement on how to proceed with > this RC? I had been holding off my own verification and voting due to the > open question. > > I'm available to verify an RC tonight and tomorrow. After Friday, 4/8 at > 3 PM PST, I'll be unavailable through at least 4/18. > > --Chris Nauroth > > > > > On 4/5/16, 4:36 AM, "Kengo Seki" <[email protected]> wrote: > >>> For example, Say 0.2.2 is made after we've had a 0.3.0 release. >>> Would I backport both the change for 0.2.1's release and 0.3.0's? >>> When 0.3.1 comes out do I backport the notice for 0.2.2? >> >>Sorry for not explaining enough, I didn't intend to backport 0.3.x >>into 0.2.x. I simply thought it might be natural that 0.2.1 contains >>documents for 0.1.0, 0.2.0 and 0.2.1 because 0.2.1 is based on 0.2.0. >> >>But in this case, the difference between 0.2.0 and 0.2.1 is very small >>and obvious from the changelog. In addition, users can check online >>document for 0.2.0 and 0.2.1 after release. So I approve #1 and +1 for >>this RC now. >> >>> On the other hand, we could just have a step of copying the files that >>> change with a successful release directly from then-current master. >>> That would get all of the changes without needing to go searching for >>> the individual commits. HBase does this for docs and it works okay. >> >>That sounds good to me. I'll file it as a JIRA later. >> >>2016-04-05 6:22 GMT+09:00 Sean Busbey <[email protected]>: >>> On Mon, Apr 4, 2016 at 12:31 PM, Kengo Seki <[email protected]> wrote: >>>> I'm +0 for now. >>>> My concern is that YETUS-318-website.patch seems not to be included >>>> this RC. Should we merge this? >>>> If it's unnecessary, I'm +1 (binding). I checked the followings: >>>> >>> >>> >>> ... interesting. This comes down to what we want in our release >>> process, I think. The post-release-vote website changes always go into >>> some future minor release, by virtue of our current instructions. That >>> means if we want to be able to cut maintenance releases off of the >>> prior minor release we have to either >>> >>> 1) accept that you can't build a correct website off of the >>> maintenance release source >>> >>> 2) backport needed website changes onto the maintenance branch >>> >>> I lean towards #1 just as a matter of logistics. For example, Say >>> 0.2.2 is made after we've had a 0.3.0 release. Would I backport both >>> the change for 0.2.1's release and 0.3.0's? When 0.3.1 comes out do I >>> backport the notice for 0.2.2? Do we do this for every release that's >>> happened since the last maintenance release? Are we setting ourselves >>> up for an ever-increasing amount of work then? >>> >>> On the other hand, we could just have a step of copying the files that >>> change with a successful release directly from then-current master. >>> That would get all of the changes without needing to go searching for >>> the individual commits. HBase does this for docs and it works okay. >> >> >> >>-- >>Kengo Seki <[email protected]> >> >
