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