Re: [DISCUSS] Keep EOL HBase and Hadoop versions in our support matrix for longer time
Revive. Forgot to push this forward... 张铎(Duo Zhang) 于2022年1月24日周一 17:44写道: > Seems no big concern. > > Let me start the work. > > 张铎(Duo Zhang) 于2022年1月16日周日 16:20写道: > >> Let's wait several more days. If no objections, I will start with the >> plan. >> >> Thanks. >> >> Andrew Purtell 于2022年1月10日周一 08:16写道: >> >>> That sounds like a pretty good plan to me. What do others think? >>> >>> On Sun, Jan 9, 2022 at 4:04 PM 张铎(Duo Zhang) >>> wrote: >>> >>> > That's also a possible solution, I mean remove purge the docs in >>> branches >>> > other than master. >>> > >>> > So what should be done will be: >>> > 1. Remove all docs from branches other than master. >>> > 2. See how to skip the doc generating when docs are not there so we do >>> not >>> > break the publishing release process. >>> > 3. Modify the documentation to also include the information about EOL >>> > releases, instead of just purging them from the documentation. >>> > >>> > WDYT? >>> > >>> > Thanks. >>> > >>> > Andrew Purtell 于2022年1月10日周一 01:28写道: >>> > >>> > > Our branch-1 release process included a step to check out master and >>> > > overwrite root src/ to do just that, manually synchronize docs for >>> all >>> > > releases. >>> > > >>> > > I do not believe we can keep docs in branches effectively >>> synchronized. >>> > > Periodic manual sweeps could work but is still error prone. It would >>> be >>> > > better to remove docs from all branches other than master and then >>> there >>> > > will be one copy only to maintain … that will be feasible. >>> > > >>> > > > On Jan 9, 2022, at 4:39 AM, 张铎 wrote: >>> > > > >>> > > > Ouch. IIRC there are lots of documentation improvements only get >>> > > > merged to master branch only... >>> > > > >>> > > > I think the fact for now is that, it is a bit hard for us to keep >>> the >>> > > > documentation for each minor release in sync correctly... >>> > > > Since we will publish the ref guide as part of our releases, let's >>> > > > just introduce a simple rule, keep the ref guide for all active >>> > > > branches always the same, and once a release line gets EOL, we will >>> > > > not update its ref guide any more. >>> > > > At least for me this rule is not very hard to follow... >>> > > > >>> > > > Thanks. >>> > > > >>> > > > Sean Busbey 于2022年1月9日周日 17:15写道: >>> > > >> >>> > > >> We already publish version specific reference guides as a part of >>> our >>> > > >> binary tarballs. My understanding is that's a big part of why >>> they're >>> > > >> still in the main source repository; that we get docs built as a >>> part >>> > > >> of our assembly. >>> > > >> >>> > > >> e.g. just picking a 2.4 release I have handy: >>> > > >> >>> > > >> (base) sbusbey@seans-mbp ~ % tar tzf >>> > Downloads/hbase-2.4.8-bin.tar.gz| >>> > > >> grep pdf >>> > > >> hbase-2.4.8/docs/apache_hbase_reference_guide.pdf >>> > > >> (base) sbusbey@seans-mbp ~ % tar tzf >>> > Downloads/hbase-2.4.8-bin.tar.gz| >>> > > >> grep book.html >>> > > >> hbase-2.4.8/docs/book.html >>> > > >> >>> > > >> Historically these do get maintained for each minor version. My >>> > > >> understanding is that the diligence on backporting across both >>> > > >> contributors to docs and release managers has varied considerably >>> over >>> > > >> time. >>> > > >> >>> > > >> If we're only going to have one version of the docs, then we >>> should >>> > > >> break the docs out of the main repo entirely so that we can >>> simplify >>> > > >> their generation. >>> > > >> >>> > > >> IIRC we have only gone through the trouble of publishing to the >>> > > >> website version specific API docs / ref guides for release lines >>> that >>> > > >> made it to be the "stable" branch. >>> > > >> >>> > > >>> On Sat, Jan 8, 2022 at 9:37 AM 张铎(Duo Zhang) < >>> palomino...@gmail.com> >>> > > wrote: >>> > > >>> >>> > > >>> I agree with Andrew that maybe it is beyond our ability to >>> maintain >>> > > >>> ref guides for different release lines and keep them all in >>> sync... >>> > > >>> >>> > > >>> What about this, we just make the ref guide for the master >>> branch in >>> > > >>> sync, which contains all release lines. We will still remove >>> > > >>> information of the EOL releases as needed, to keep the ref guide >>> > > >>> clean, but as said in the title, less aggressive. >>> > > >>> And when we decide to EOL a release line, we copy the ref guide >>> of >>> > the >>> > > >>> current master branch to the specific branch, and generate the >>> ref >>> > > >>> guide for that release line for the last time. >>> > > >>> In this way the release manager does not need to always think of >>> > > >>> keeping the ref guide in sync, we all just need to consider the >>> > master >>> > > >>> one, only one extra work needs to be done when EOLing a release >>> line. >>> > > >>> >>> > > >>> WDYT? >>> > > >>> >>> > > >>> Thanks. >>> > > >>> >>> > > >>> Andrew Purtell 于2022年1月8日周六 07:16写道: >>> > > >>> > > There are some challenges with respect to keeping multiple >>> vers
Re: [DISCUSS] Keep EOL HBase and Hadoop versions in our support matrix for longer time
Seems no big concern. Let me start the work. 张铎(Duo Zhang) 于2022年1月16日周日 16:20写道: > Let's wait several more days. If no objections, I will start with the plan. > > Thanks. > > Andrew Purtell 于2022年1月10日周一 08:16写道: > >> That sounds like a pretty good plan to me. What do others think? >> >> On Sun, Jan 9, 2022 at 4:04 PM 张铎(Duo Zhang) >> wrote: >> >> > That's also a possible solution, I mean remove purge the docs in >> branches >> > other than master. >> > >> > So what should be done will be: >> > 1. Remove all docs from branches other than master. >> > 2. See how to skip the doc generating when docs are not there so we do >> not >> > break the publishing release process. >> > 3. Modify the documentation to also include the information about EOL >> > releases, instead of just purging them from the documentation. >> > >> > WDYT? >> > >> > Thanks. >> > >> > Andrew Purtell 于2022年1月10日周一 01:28写道: >> > >> > > Our branch-1 release process included a step to check out master and >> > > overwrite root src/ to do just that, manually synchronize docs for all >> > > releases. >> > > >> > > I do not believe we can keep docs in branches effectively >> synchronized. >> > > Periodic manual sweeps could work but is still error prone. It would >> be >> > > better to remove docs from all branches other than master and then >> there >> > > will be one copy only to maintain … that will be feasible. >> > > >> > > > On Jan 9, 2022, at 4:39 AM, 张铎 wrote: >> > > > >> > > > Ouch. IIRC there are lots of documentation improvements only get >> > > > merged to master branch only... >> > > > >> > > > I think the fact for now is that, it is a bit hard for us to keep >> the >> > > > documentation for each minor release in sync correctly... >> > > > Since we will publish the ref guide as part of our releases, let's >> > > > just introduce a simple rule, keep the ref guide for all active >> > > > branches always the same, and once a release line gets EOL, we will >> > > > not update its ref guide any more. >> > > > At least for me this rule is not very hard to follow... >> > > > >> > > > Thanks. >> > > > >> > > > Sean Busbey 于2022年1月9日周日 17:15写道: >> > > >> >> > > >> We already publish version specific reference guides as a part of >> our >> > > >> binary tarballs. My understanding is that's a big part of why >> they're >> > > >> still in the main source repository; that we get docs built as a >> part >> > > >> of our assembly. >> > > >> >> > > >> e.g. just picking a 2.4 release I have handy: >> > > >> >> > > >> (base) sbusbey@seans-mbp ~ % tar tzf >> > Downloads/hbase-2.4.8-bin.tar.gz| >> > > >> grep pdf >> > > >> hbase-2.4.8/docs/apache_hbase_reference_guide.pdf >> > > >> (base) sbusbey@seans-mbp ~ % tar tzf >> > Downloads/hbase-2.4.8-bin.tar.gz| >> > > >> grep book.html >> > > >> hbase-2.4.8/docs/book.html >> > > >> >> > > >> Historically these do get maintained for each minor version. My >> > > >> understanding is that the diligence on backporting across both >> > > >> contributors to docs and release managers has varied considerably >> over >> > > >> time. >> > > >> >> > > >> If we're only going to have one version of the docs, then we should >> > > >> break the docs out of the main repo entirely so that we can >> simplify >> > > >> their generation. >> > > >> >> > > >> IIRC we have only gone through the trouble of publishing to the >> > > >> website version specific API docs / ref guides for release lines >> that >> > > >> made it to be the "stable" branch. >> > > >> >> > > >>> On Sat, Jan 8, 2022 at 9:37 AM 张铎(Duo Zhang) < >> palomino...@gmail.com> >> > > wrote: >> > > >>> >> > > >>> I agree with Andrew that maybe it is beyond our ability to >> maintain >> > > >>> ref guides for different release lines and keep them all in >> sync... >> > > >>> >> > > >>> What about this, we just make the ref guide for the master branch >> in >> > > >>> sync, which contains all release lines. We will still remove >> > > >>> information of the EOL releases as needed, to keep the ref guide >> > > >>> clean, but as said in the title, less aggressive. >> > > >>> And when we decide to EOL a release line, we copy the ref guide of >> > the >> > > >>> current master branch to the specific branch, and generate the ref >> > > >>> guide for that release line for the last time. >> > > >>> In this way the release manager does not need to always think of >> > > >>> keeping the ref guide in sync, we all just need to consider the >> > master >> > > >>> one, only one extra work needs to be done when EOLing a release >> line. >> > > >>> >> > > >>> WDYT? >> > > >>> >> > > >>> Thanks. >> > > >>> >> > > >>> Andrew Purtell 于2022年1月8日周六 07:16写道: >> > > >> > > There are some challenges with respect to keeping multiple >> versions >> > > of the >> > > documentation around. Each minor release needs a new version? >> Each >> > RM >> > > managing one or more code line(s) needs to update trunk docs and >> > also >> > > backport to branch docs (o
Re: [DISCUSS] Keep EOL HBase and Hadoop versions in our support matrix for longer time
Let's wait several more days. If no objections, I will start with the plan. Thanks. Andrew Purtell 于2022年1月10日周一 08:16写道: > That sounds like a pretty good plan to me. What do others think? > > On Sun, Jan 9, 2022 at 4:04 PM 张铎(Duo Zhang) > wrote: > > > That's also a possible solution, I mean remove purge the docs in branches > > other than master. > > > > So what should be done will be: > > 1. Remove all docs from branches other than master. > > 2. See how to skip the doc generating when docs are not there so we do > not > > break the publishing release process. > > 3. Modify the documentation to also include the information about EOL > > releases, instead of just purging them from the documentation. > > > > WDYT? > > > > Thanks. > > > > Andrew Purtell 于2022年1月10日周一 01:28写道: > > > > > Our branch-1 release process included a step to check out master and > > > overwrite root src/ to do just that, manually synchronize docs for all > > > releases. > > > > > > I do not believe we can keep docs in branches effectively synchronized. > > > Periodic manual sweeps could work but is still error prone. It would be > > > better to remove docs from all branches other than master and then > there > > > will be one copy only to maintain … that will be feasible. > > > > > > > On Jan 9, 2022, at 4:39 AM, 张铎 wrote: > > > > > > > > Ouch. IIRC there are lots of documentation improvements only get > > > > merged to master branch only... > > > > > > > > I think the fact for now is that, it is a bit hard for us to keep the > > > > documentation for each minor release in sync correctly... > > > > Since we will publish the ref guide as part of our releases, let's > > > > just introduce a simple rule, keep the ref guide for all active > > > > branches always the same, and once a release line gets EOL, we will > > > > not update its ref guide any more. > > > > At least for me this rule is not very hard to follow... > > > > > > > > Thanks. > > > > > > > > Sean Busbey 于2022年1月9日周日 17:15写道: > > > >> > > > >> We already publish version specific reference guides as a part of > our > > > >> binary tarballs. My understanding is that's a big part of why > they're > > > >> still in the main source repository; that we get docs built as a > part > > > >> of our assembly. > > > >> > > > >> e.g. just picking a 2.4 release I have handy: > > > >> > > > >> (base) sbusbey@seans-mbp ~ % tar tzf > > Downloads/hbase-2.4.8-bin.tar.gz| > > > >> grep pdf > > > >> hbase-2.4.8/docs/apache_hbase_reference_guide.pdf > > > >> (base) sbusbey@seans-mbp ~ % tar tzf > > Downloads/hbase-2.4.8-bin.tar.gz| > > > >> grep book.html > > > >> hbase-2.4.8/docs/book.html > > > >> > > > >> Historically these do get maintained for each minor version. My > > > >> understanding is that the diligence on backporting across both > > > >> contributors to docs and release managers has varied considerably > over > > > >> time. > > > >> > > > >> If we're only going to have one version of the docs, then we should > > > >> break the docs out of the main repo entirely so that we can simplify > > > >> their generation. > > > >> > > > >> IIRC we have only gone through the trouble of publishing to the > > > >> website version specific API docs / ref guides for release lines > that > > > >> made it to be the "stable" branch. > > > >> > > > >>> On Sat, Jan 8, 2022 at 9:37 AM 张铎(Duo Zhang) < > palomino...@gmail.com> > > > wrote: > > > >>> > > > >>> I agree with Andrew that maybe it is beyond our ability to maintain > > > >>> ref guides for different release lines and keep them all in sync... > > > >>> > > > >>> What about this, we just make the ref guide for the master branch > in > > > >>> sync, which contains all release lines. We will still remove > > > >>> information of the EOL releases as needed, to keep the ref guide > > > >>> clean, but as said in the title, less aggressive. > > > >>> And when we decide to EOL a release line, we copy the ref guide of > > the > > > >>> current master branch to the specific branch, and generate the ref > > > >>> guide for that release line for the last time. > > > >>> In this way the release manager does not need to always think of > > > >>> keeping the ref guide in sync, we all just need to consider the > > master > > > >>> one, only one extra work needs to be done when EOLing a release > line. > > > >>> > > > >>> WDYT? > > > >>> > > > >>> Thanks. > > > >>> > > > >>> Andrew Purtell 于2022年1月8日周六 07:16写道: > > > > > > There are some challenges with respect to keeping multiple > versions > > > of the > > > documentation around. Each minor release needs a new version? Each > > RM > > > managing one or more code line(s) needs to update trunk docs and > > also > > > backport to branch docs (or not, depending)? There's been a JIRA > > open > > > forever for a 2.4 version of the book and honestly I haven't found > > > time to > > > do it, because it seems both low priority and nontrivial, and > > there's > > > never >
Re: [DISCUSS] Keep EOL HBase and Hadoop versions in our support matrix for longer time
That sounds like a pretty good plan to me. What do others think? On Sun, Jan 9, 2022 at 4:04 PM 张铎(Duo Zhang) wrote: > That's also a possible solution, I mean remove purge the docs in branches > other than master. > > So what should be done will be: > 1. Remove all docs from branches other than master. > 2. See how to skip the doc generating when docs are not there so we do not > break the publishing release process. > 3. Modify the documentation to also include the information about EOL > releases, instead of just purging them from the documentation. > > WDYT? > > Thanks. > > Andrew Purtell 于2022年1月10日周一 01:28写道: > > > Our branch-1 release process included a step to check out master and > > overwrite root src/ to do just that, manually synchronize docs for all > > releases. > > > > I do not believe we can keep docs in branches effectively synchronized. > > Periodic manual sweeps could work but is still error prone. It would be > > better to remove docs from all branches other than master and then there > > will be one copy only to maintain … that will be feasible. > > > > > On Jan 9, 2022, at 4:39 AM, 张铎 wrote: > > > > > > Ouch. IIRC there are lots of documentation improvements only get > > > merged to master branch only... > > > > > > I think the fact for now is that, it is a bit hard for us to keep the > > > documentation for each minor release in sync correctly... > > > Since we will publish the ref guide as part of our releases, let's > > > just introduce a simple rule, keep the ref guide for all active > > > branches always the same, and once a release line gets EOL, we will > > > not update its ref guide any more. > > > At least for me this rule is not very hard to follow... > > > > > > Thanks. > > > > > > Sean Busbey 于2022年1月9日周日 17:15写道: > > >> > > >> We already publish version specific reference guides as a part of our > > >> binary tarballs. My understanding is that's a big part of why they're > > >> still in the main source repository; that we get docs built as a part > > >> of our assembly. > > >> > > >> e.g. just picking a 2.4 release I have handy: > > >> > > >> (base) sbusbey@seans-mbp ~ % tar tzf > Downloads/hbase-2.4.8-bin.tar.gz| > > >> grep pdf > > >> hbase-2.4.8/docs/apache_hbase_reference_guide.pdf > > >> (base) sbusbey@seans-mbp ~ % tar tzf > Downloads/hbase-2.4.8-bin.tar.gz| > > >> grep book.html > > >> hbase-2.4.8/docs/book.html > > >> > > >> Historically these do get maintained for each minor version. My > > >> understanding is that the diligence on backporting across both > > >> contributors to docs and release managers has varied considerably over > > >> time. > > >> > > >> If we're only going to have one version of the docs, then we should > > >> break the docs out of the main repo entirely so that we can simplify > > >> their generation. > > >> > > >> IIRC we have only gone through the trouble of publishing to the > > >> website version specific API docs / ref guides for release lines that > > >> made it to be the "stable" branch. > > >> > > >>> On Sat, Jan 8, 2022 at 9:37 AM 张铎(Duo Zhang) > > wrote: > > >>> > > >>> I agree with Andrew that maybe it is beyond our ability to maintain > > >>> ref guides for different release lines and keep them all in sync... > > >>> > > >>> What about this, we just make the ref guide for the master branch in > > >>> sync, which contains all release lines. We will still remove > > >>> information of the EOL releases as needed, to keep the ref guide > > >>> clean, but as said in the title, less aggressive. > > >>> And when we decide to EOL a release line, we copy the ref guide of > the > > >>> current master branch to the specific branch, and generate the ref > > >>> guide for that release line for the last time. > > >>> In this way the release manager does not need to always think of > > >>> keeping the ref guide in sync, we all just need to consider the > master > > >>> one, only one extra work needs to be done when EOLing a release line. > > >>> > > >>> WDYT? > > >>> > > >>> Thanks. > > >>> > > >>> Andrew Purtell 于2022年1月8日周六 07:16写道: > > > > There are some challenges with respect to keeping multiple versions > > of the > > documentation around. Each minor release needs a new version? Each > RM > > managing one or more code line(s) needs to update trunk docs and > also > > backport to branch docs (or not, depending)? There's been a JIRA > open > > forever for a 2.4 version of the book and honestly I haven't found > > time to > > do it, because it seems both low priority and nontrivial, and > there's > > never > > enough time for everything... although that may be a personal > failing. > > > > On Fri, Jan 7, 2022 at 9:05 AM Sean Busbey > wrote: > > > > > We should have a version specific version of the ref guide that > > > contains that information. > > > > > > e.g. > > > > > > https://hbase.apache.org/1.4/book.html#hadoop > > > > > > https://hbase.a
Re: [DISCUSS] Keep EOL HBase and Hadoop versions in our support matrix for longer time
That's also a possible solution, I mean remove purge the docs in branches other than master. So what should be done will be: 1. Remove all docs from branches other than master. 2. See how to skip the doc generating when docs are not there so we do not break the publishing release process. 3. Modify the documentation to also include the information about EOL releases, instead of just purging them from the documentation. WDYT? Thanks. Andrew Purtell 于2022年1月10日周一 01:28写道: > Our branch-1 release process included a step to check out master and > overwrite root src/ to do just that, manually synchronize docs for all > releases. > > I do not believe we can keep docs in branches effectively synchronized. > Periodic manual sweeps could work but is still error prone. It would be > better to remove docs from all branches other than master and then there > will be one copy only to maintain … that will be feasible. > > > On Jan 9, 2022, at 4:39 AM, 张铎 wrote: > > > > Ouch. IIRC there are lots of documentation improvements only get > > merged to master branch only... > > > > I think the fact for now is that, it is a bit hard for us to keep the > > documentation for each minor release in sync correctly... > > Since we will publish the ref guide as part of our releases, let's > > just introduce a simple rule, keep the ref guide for all active > > branches always the same, and once a release line gets EOL, we will > > not update its ref guide any more. > > At least for me this rule is not very hard to follow... > > > > Thanks. > > > > Sean Busbey 于2022年1月9日周日 17:15写道: > >> > >> We already publish version specific reference guides as a part of our > >> binary tarballs. My understanding is that's a big part of why they're > >> still in the main source repository; that we get docs built as a part > >> of our assembly. > >> > >> e.g. just picking a 2.4 release I have handy: > >> > >> (base) sbusbey@seans-mbp ~ % tar tzf Downloads/hbase-2.4.8-bin.tar.gz| > >> grep pdf > >> hbase-2.4.8/docs/apache_hbase_reference_guide.pdf > >> (base) sbusbey@seans-mbp ~ % tar tzf Downloads/hbase-2.4.8-bin.tar.gz| > >> grep book.html > >> hbase-2.4.8/docs/book.html > >> > >> Historically these do get maintained for each minor version. My > >> understanding is that the diligence on backporting across both > >> contributors to docs and release managers has varied considerably over > >> time. > >> > >> If we're only going to have one version of the docs, then we should > >> break the docs out of the main repo entirely so that we can simplify > >> their generation. > >> > >> IIRC we have only gone through the trouble of publishing to the > >> website version specific API docs / ref guides for release lines that > >> made it to be the "stable" branch. > >> > >>> On Sat, Jan 8, 2022 at 9:37 AM 张铎(Duo Zhang) > wrote: > >>> > >>> I agree with Andrew that maybe it is beyond our ability to maintain > >>> ref guides for different release lines and keep them all in sync... > >>> > >>> What about this, we just make the ref guide for the master branch in > >>> sync, which contains all release lines. We will still remove > >>> information of the EOL releases as needed, to keep the ref guide > >>> clean, but as said in the title, less aggressive. > >>> And when we decide to EOL a release line, we copy the ref guide of the > >>> current master branch to the specific branch, and generate the ref > >>> guide for that release line for the last time. > >>> In this way the release manager does not need to always think of > >>> keeping the ref guide in sync, we all just need to consider the master > >>> one, only one extra work needs to be done when EOLing a release line. > >>> > >>> WDYT? > >>> > >>> Thanks. > >>> > >>> Andrew Purtell 于2022年1月8日周六 07:16写道: > > There are some challenges with respect to keeping multiple versions > of the > documentation around. Each minor release needs a new version? Each RM > managing one or more code line(s) needs to update trunk docs and also > backport to branch docs (or not, depending)? There's been a JIRA open > forever for a 2.4 version of the book and honestly I haven't found > time to > do it, because it seems both low priority and nontrivial, and there's > never > enough time for everything... although that may be a personal failing. > > On Fri, Jan 7, 2022 at 9:05 AM Sean Busbey wrote: > > > We should have a version specific version of the ref guide that > > contains that information. > > > > e.g. > > > > https://hbase.apache.org/1.4/book.html#hadoop > > > > https://hbase.apache.org/2.3/book.html#hadoop > > > > Can we do a better job of making these discoverable to folks rather > > than keeping stuff around? > > > > On Fri, Jan 7, 2022 at 1:14 AM 张铎(Duo Zhang) > > wrote: > >> > >> Recently we've seen several emails on the user list asking whether > >> some hbase versions support specific had
Re: [DISCUSS] Keep EOL HBase and Hadoop versions in our support matrix for longer time
Our branch-1 release process included a step to check out master and overwrite root src/ to do just that, manually synchronize docs for all releases. I do not believe we can keep docs in branches effectively synchronized. Periodic manual sweeps could work but is still error prone. It would be better to remove docs from all branches other than master and then there will be one copy only to maintain … that will be feasible. > On Jan 9, 2022, at 4:39 AM, 张铎 wrote: > > Ouch. IIRC there are lots of documentation improvements only get > merged to master branch only... > > I think the fact for now is that, it is a bit hard for us to keep the > documentation for each minor release in sync correctly... > Since we will publish the ref guide as part of our releases, let's > just introduce a simple rule, keep the ref guide for all active > branches always the same, and once a release line gets EOL, we will > not update its ref guide any more. > At least for me this rule is not very hard to follow... > > Thanks. > > Sean Busbey 于2022年1月9日周日 17:15写道: >> >> We already publish version specific reference guides as a part of our >> binary tarballs. My understanding is that's a big part of why they're >> still in the main source repository; that we get docs built as a part >> of our assembly. >> >> e.g. just picking a 2.4 release I have handy: >> >> (base) sbusbey@seans-mbp ~ % tar tzf Downloads/hbase-2.4.8-bin.tar.gz| >> grep pdf >> hbase-2.4.8/docs/apache_hbase_reference_guide.pdf >> (base) sbusbey@seans-mbp ~ % tar tzf Downloads/hbase-2.4.8-bin.tar.gz| >> grep book.html >> hbase-2.4.8/docs/book.html >> >> Historically these do get maintained for each minor version. My >> understanding is that the diligence on backporting across both >> contributors to docs and release managers has varied considerably over >> time. >> >> If we're only going to have one version of the docs, then we should >> break the docs out of the main repo entirely so that we can simplify >> their generation. >> >> IIRC we have only gone through the trouble of publishing to the >> website version specific API docs / ref guides for release lines that >> made it to be the "stable" branch. >> >>> On Sat, Jan 8, 2022 at 9:37 AM 张铎(Duo Zhang) wrote: >>> >>> I agree with Andrew that maybe it is beyond our ability to maintain >>> ref guides for different release lines and keep them all in sync... >>> >>> What about this, we just make the ref guide for the master branch in >>> sync, which contains all release lines. We will still remove >>> information of the EOL releases as needed, to keep the ref guide >>> clean, but as said in the title, less aggressive. >>> And when we decide to EOL a release line, we copy the ref guide of the >>> current master branch to the specific branch, and generate the ref >>> guide for that release line for the last time. >>> In this way the release manager does not need to always think of >>> keeping the ref guide in sync, we all just need to consider the master >>> one, only one extra work needs to be done when EOLing a release line. >>> >>> WDYT? >>> >>> Thanks. >>> >>> Andrew Purtell 于2022年1月8日周六 07:16写道: There are some challenges with respect to keeping multiple versions of the documentation around. Each minor release needs a new version? Each RM managing one or more code line(s) needs to update trunk docs and also backport to branch docs (or not, depending)? There's been a JIRA open forever for a 2.4 version of the book and honestly I haven't found time to do it, because it seems both low priority and nontrivial, and there's never enough time for everything... although that may be a personal failing. On Fri, Jan 7, 2022 at 9:05 AM Sean Busbey wrote: > We should have a version specific version of the ref guide that > contains that information. > > e.g. > > https://hbase.apache.org/1.4/book.html#hadoop > > https://hbase.apache.org/2.3/book.html#hadoop > > Can we do a better job of making these discoverable to folks rather > than keeping stuff around? > > On Fri, Jan 7, 2022 at 1:14 AM 张铎(Duo Zhang) > wrote: >> >> Recently we've seen several emails on the user list asking whether >> some hbase versions support specific hadoop versions, usually it will >> be some versions which are already EOL, so there is no information in >> our ref guide. >> >> For me I think we could leave the EOL versions in the support matrix >> for a bit longer. It will be useful for our users. >> >> Thanks. > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
Re: [DISCUSS] Keep EOL HBase and Hadoop versions in our support matrix for longer time
As you say the docs on branches are not updated in any principled way. Extracting the Javadoc from a matrix of branch builds in a automated way for publishing up to the website would be feasible. We can add this to the build website Jenkins job. On the other hand, this thread’s topic, a support matrix, would need to be updated by hand whenever a change of consequence is backported. We can expect that committers backporting a change breaking old dependencies won’t know about or recall the branch support matrixes. History teaches us they might not even be aware the change breaks support. The RM won’t catch it with the default build. We would need a matrix of compatibility test jobs to catch the cases that fall through the cracks. > On Jan 9, 2022, at 1:15 AM, Sean Busbey wrote: > > We already publish version specific reference guides as a part of our > binary tarballs. My understanding is that's a big part of why they're > still in the main source repository; that we get docs built as a part > of our assembly. > > e.g. just picking a 2.4 release I have handy: > > (base) sbusbey@seans-mbp ~ % tar tzf Downloads/hbase-2.4.8-bin.tar.gz| > grep pdf > hbase-2.4.8/docs/apache_hbase_reference_guide.pdf > (base) sbusbey@seans-mbp ~ % tar tzf Downloads/hbase-2.4.8-bin.tar.gz| > grep book.html > hbase-2.4.8/docs/book.html > > Historically these do get maintained for each minor version. My > understanding is that the diligence on backporting across both > contributors to docs and release managers has varied considerably over > time. > > If we're only going to have one version of the docs, then we should > break the docs out of the main repo entirely so that we can simplify > their generation. > > IIRC we have only gone through the trouble of publishing to the > website version specific API docs / ref guides for release lines that > made it to be the "stable" branch. > >> On Sat, Jan 8, 2022 at 9:37 AM 张铎(Duo Zhang) wrote: >> >> I agree with Andrew that maybe it is beyond our ability to maintain >> ref guides for different release lines and keep them all in sync... >> >> What about this, we just make the ref guide for the master branch in >> sync, which contains all release lines. We will still remove >> information of the EOL releases as needed, to keep the ref guide >> clean, but as said in the title, less aggressive. >> And when we decide to EOL a release line, we copy the ref guide of the >> current master branch to the specific branch, and generate the ref >> guide for that release line for the last time. >> In this way the release manager does not need to always think of >> keeping the ref guide in sync, we all just need to consider the master >> one, only one extra work needs to be done when EOLing a release line. >> >> WDYT? >> >> Thanks. >> >> Andrew Purtell 于2022年1月8日周六 07:16写道: >>> >>> There are some challenges with respect to keeping multiple versions of the >>> documentation around. Each minor release needs a new version? Each RM >>> managing one or more code line(s) needs to update trunk docs and also >>> backport to branch docs (or not, depending)? There's been a JIRA open >>> forever for a 2.4 version of the book and honestly I haven't found time to >>> do it, because it seems both low priority and nontrivial, and there's never >>> enough time for everything... although that may be a personal failing. >>> On Fri, Jan 7, 2022 at 9:05 AM Sean Busbey wrote: >>> We should have a version specific version of the ref guide that contains that information. e.g. https://hbase.apache.org/1.4/book.html#hadoop https://hbase.apache.org/2.3/book.html#hadoop Can we do a better job of making these discoverable to folks rather than keeping stuff around? On Fri, Jan 7, 2022 at 1:14 AM 张铎(Duo Zhang) wrote: > > Recently we've seen several emails on the user list asking whether > some hbase versions support specific hadoop versions, usually it will > be some versions which are already EOL, so there is no information in > our ref guide. > > For me I think we could leave the EOL versions in the support matrix > for a bit longer. It will be useful for our users. > > Thanks. >>> >>> >>> -- >>> Best regards, >>> Andrew >>> >>> Words like orphans lost among the crosstalk, meaning torn from truth's >>> decrepit hands >>> - A23, Crosstalk
Re: [DISCUSS] Keep EOL HBase and Hadoop versions in our support matrix for longer time
Ouch. IIRC there are lots of documentation improvements only get merged to master branch only... I think the fact for now is that, it is a bit hard for us to keep the documentation for each minor release in sync correctly... Since we will publish the ref guide as part of our releases, let's just introduce a simple rule, keep the ref guide for all active branches always the same, and once a release line gets EOL, we will not update its ref guide any more. At least for me this rule is not very hard to follow... Thanks. Sean Busbey 于2022年1月9日周日 17:15写道: > > We already publish version specific reference guides as a part of our > binary tarballs. My understanding is that's a big part of why they're > still in the main source repository; that we get docs built as a part > of our assembly. > > e.g. just picking a 2.4 release I have handy: > > (base) sbusbey@seans-mbp ~ % tar tzf Downloads/hbase-2.4.8-bin.tar.gz| > grep pdf > hbase-2.4.8/docs/apache_hbase_reference_guide.pdf > (base) sbusbey@seans-mbp ~ % tar tzf Downloads/hbase-2.4.8-bin.tar.gz| > grep book.html > hbase-2.4.8/docs/book.html > > Historically these do get maintained for each minor version. My > understanding is that the diligence on backporting across both > contributors to docs and release managers has varied considerably over > time. > > If we're only going to have one version of the docs, then we should > break the docs out of the main repo entirely so that we can simplify > their generation. > > IIRC we have only gone through the trouble of publishing to the > website version specific API docs / ref guides for release lines that > made it to be the "stable" branch. > > On Sat, Jan 8, 2022 at 9:37 AM 张铎(Duo Zhang) wrote: > > > > I agree with Andrew that maybe it is beyond our ability to maintain > > ref guides for different release lines and keep them all in sync... > > > > What about this, we just make the ref guide for the master branch in > > sync, which contains all release lines. We will still remove > > information of the EOL releases as needed, to keep the ref guide > > clean, but as said in the title, less aggressive. > > And when we decide to EOL a release line, we copy the ref guide of the > > current master branch to the specific branch, and generate the ref > > guide for that release line for the last time. > > In this way the release manager does not need to always think of > > keeping the ref guide in sync, we all just need to consider the master > > one, only one extra work needs to be done when EOLing a release line. > > > > WDYT? > > > > Thanks. > > > > Andrew Purtell 于2022年1月8日周六 07:16写道: > > > > > > There are some challenges with respect to keeping multiple versions of the > > > documentation around. Each minor release needs a new version? Each RM > > > managing one or more code line(s) needs to update trunk docs and also > > > backport to branch docs (or not, depending)? There's been a JIRA open > > > forever for a 2.4 version of the book and honestly I haven't found time to > > > do it, because it seems both low priority and nontrivial, and there's > > > never > > > enough time for everything... although that may be a personal failing. > > > > > > On Fri, Jan 7, 2022 at 9:05 AM Sean Busbey wrote: > > > > > > > We should have a version specific version of the ref guide that > > > > contains that information. > > > > > > > > e.g. > > > > > > > > https://hbase.apache.org/1.4/book.html#hadoop > > > > > > > > https://hbase.apache.org/2.3/book.html#hadoop > > > > > > > > Can we do a better job of making these discoverable to folks rather > > > > than keeping stuff around? > > > > > > > > On Fri, Jan 7, 2022 at 1:14 AM 张铎(Duo Zhang) > > > > wrote: > > > > > > > > > > Recently we've seen several emails on the user list asking whether > > > > > some hbase versions support specific hadoop versions, usually it will > > > > > be some versions which are already EOL, so there is no information in > > > > > our ref guide. > > > > > > > > > > For me I think we could leave the EOL versions in the support matrix > > > > > for a bit longer. It will be useful for our users. > > > > > > > > > > Thanks. > > > > > > > > > > > > > -- > > > Best regards, > > > Andrew > > > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > > decrepit hands > > >- A23, Crosstalk
Re: [DISCUSS] Keep EOL HBase and Hadoop versions in our support matrix for longer time
We already publish version specific reference guides as a part of our binary tarballs. My understanding is that's a big part of why they're still in the main source repository; that we get docs built as a part of our assembly. e.g. just picking a 2.4 release I have handy: (base) sbusbey@seans-mbp ~ % tar tzf Downloads/hbase-2.4.8-bin.tar.gz| grep pdf hbase-2.4.8/docs/apache_hbase_reference_guide.pdf (base) sbusbey@seans-mbp ~ % tar tzf Downloads/hbase-2.4.8-bin.tar.gz| grep book.html hbase-2.4.8/docs/book.html Historically these do get maintained for each minor version. My understanding is that the diligence on backporting across both contributors to docs and release managers has varied considerably over time. If we're only going to have one version of the docs, then we should break the docs out of the main repo entirely so that we can simplify their generation. IIRC we have only gone through the trouble of publishing to the website version specific API docs / ref guides for release lines that made it to be the "stable" branch. On Sat, Jan 8, 2022 at 9:37 AM 张铎(Duo Zhang) wrote: > > I agree with Andrew that maybe it is beyond our ability to maintain > ref guides for different release lines and keep them all in sync... > > What about this, we just make the ref guide for the master branch in > sync, which contains all release lines. We will still remove > information of the EOL releases as needed, to keep the ref guide > clean, but as said in the title, less aggressive. > And when we decide to EOL a release line, we copy the ref guide of the > current master branch to the specific branch, and generate the ref > guide for that release line for the last time. > In this way the release manager does not need to always think of > keeping the ref guide in sync, we all just need to consider the master > one, only one extra work needs to be done when EOLing a release line. > > WDYT? > > Thanks. > > Andrew Purtell 于2022年1月8日周六 07:16写道: > > > > There are some challenges with respect to keeping multiple versions of the > > documentation around. Each minor release needs a new version? Each RM > > managing one or more code line(s) needs to update trunk docs and also > > backport to branch docs (or not, depending)? There's been a JIRA open > > forever for a 2.4 version of the book and honestly I haven't found time to > > do it, because it seems both low priority and nontrivial, and there's never > > enough time for everything... although that may be a personal failing. > > > > On Fri, Jan 7, 2022 at 9:05 AM Sean Busbey wrote: > > > > > We should have a version specific version of the ref guide that > > > contains that information. > > > > > > e.g. > > > > > > https://hbase.apache.org/1.4/book.html#hadoop > > > > > > https://hbase.apache.org/2.3/book.html#hadoop > > > > > > Can we do a better job of making these discoverable to folks rather > > > than keeping stuff around? > > > > > > On Fri, Jan 7, 2022 at 1:14 AM 张铎(Duo Zhang) > > > wrote: > > > > > > > > Recently we've seen several emails on the user list asking whether > > > > some hbase versions support specific hadoop versions, usually it will > > > > be some versions which are already EOL, so there is no information in > > > > our ref guide. > > > > > > > > For me I think we could leave the EOL versions in the support matrix > > > > for a bit longer. It will be useful for our users. > > > > > > > > Thanks. > > > > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > >- A23, Crosstalk
Re: [DISCUSS] Keep EOL HBase and Hadoop versions in our support matrix for longer time
I agree with Andrew that maybe it is beyond our ability to maintain ref guides for different release lines and keep them all in sync... What about this, we just make the ref guide for the master branch in sync, which contains all release lines. We will still remove information of the EOL releases as needed, to keep the ref guide clean, but as said in the title, less aggressive. And when we decide to EOL a release line, we copy the ref guide of the current master branch to the specific branch, and generate the ref guide for that release line for the last time. In this way the release manager does not need to always think of keeping the ref guide in sync, we all just need to consider the master one, only one extra work needs to be done when EOLing a release line. WDYT? Thanks. Andrew Purtell 于2022年1月8日周六 07:16写道: > > There are some challenges with respect to keeping multiple versions of the > documentation around. Each minor release needs a new version? Each RM > managing one or more code line(s) needs to update trunk docs and also > backport to branch docs (or not, depending)? There's been a JIRA open > forever for a 2.4 version of the book and honestly I haven't found time to > do it, because it seems both low priority and nontrivial, and there's never > enough time for everything... although that may be a personal failing. > > On Fri, Jan 7, 2022 at 9:05 AM Sean Busbey wrote: > > > We should have a version specific version of the ref guide that > > contains that information. > > > > e.g. > > > > https://hbase.apache.org/1.4/book.html#hadoop > > > > https://hbase.apache.org/2.3/book.html#hadoop > > > > Can we do a better job of making these discoverable to folks rather > > than keeping stuff around? > > > > On Fri, Jan 7, 2022 at 1:14 AM 张铎(Duo Zhang) > > wrote: > > > > > > Recently we've seen several emails on the user list asking whether > > > some hbase versions support specific hadoop versions, usually it will > > > be some versions which are already EOL, so there is no information in > > > our ref guide. > > > > > > For me I think we could leave the EOL versions in the support matrix > > > for a bit longer. It will be useful for our users. > > > > > > Thanks. > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk
Re: [DISCUSS] Keep EOL HBase and Hadoop versions in our support matrix for longer time
There are some challenges with respect to keeping multiple versions of the documentation around. Each minor release needs a new version? Each RM managing one or more code line(s) needs to update trunk docs and also backport to branch docs (or not, depending)? There's been a JIRA open forever for a 2.4 version of the book and honestly I haven't found time to do it, because it seems both low priority and nontrivial, and there's never enough time for everything... although that may be a personal failing. On Fri, Jan 7, 2022 at 9:05 AM Sean Busbey wrote: > We should have a version specific version of the ref guide that > contains that information. > > e.g. > > https://hbase.apache.org/1.4/book.html#hadoop > > https://hbase.apache.org/2.3/book.html#hadoop > > Can we do a better job of making these discoverable to folks rather > than keeping stuff around? > > On Fri, Jan 7, 2022 at 1:14 AM 张铎(Duo Zhang) > wrote: > > > > Recently we've seen several emails on the user list asking whether > > some hbase versions support specific hadoop versions, usually it will > > be some versions which are already EOL, so there is no information in > > our ref guide. > > > > For me I think we could leave the EOL versions in the support matrix > > for a bit longer. It will be useful for our users. > > > > Thanks. > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
Re: [DISCUSS] Keep EOL HBase and Hadoop versions in our support matrix for longer time
We should have a version specific version of the ref guide that contains that information. e.g. https://hbase.apache.org/1.4/book.html#hadoop https://hbase.apache.org/2.3/book.html#hadoop Can we do a better job of making these discoverable to folks rather than keeping stuff around? On Fri, Jan 7, 2022 at 1:14 AM 张铎(Duo Zhang) wrote: > > Recently we've seen several emails on the user list asking whether > some hbase versions support specific hadoop versions, usually it will > be some versions which are already EOL, so there is no information in > our ref guide. > > For me I think we could leave the EOL versions in the support matrix > for a bit longer. It will be useful for our users. > > Thanks.