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]> >
