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.
