I can't think better way than separating common docs and release specific docs.
This approach allows us get rid of all release specific docs (source md files) from storm site repo, and we only need to build them from storm repo and copy to publish directory of storm site repo. On the side effect, release specific docs will not expose the link to move to another releases. If we are OK to go on this approach, dropping 'First Look' section and 'Documentation' on footer would be necessary, which mean we no longer rely on 'current' release. 'Documentation' section clearly matches specific release so just good to drop. Docs in 'First Look' barely change so maybe we can bring them to the common docs, but even if we want to maintain per release manner, we can just move 'First Look' to the first of 'Documentation' page of each release. We need to have another header and footer for release specific docs so that it doesn't rely on other releases. We may also want to isolate doc links to the release specific docs, but not 100% sure this is what most of us want. 2017년 8월 2일 (수) 오전 3:29, P. Taylor Goetz <[email protected]>님이 작성: > Thanks for the heads up. If I screw something up we can always regenerate > from the release tag. > > -Taylor > > > On Aug 1, 2017, at 2:27 PM, Bobby Evans <[email protected]> > wrote: > > > > Be careful when removing the javadocs. There are links to the javadocs > from within the docs themselves. > > > > > > - Bobby > > > > > > On Tuesday, August 1, 2017, 12:57:56 PM CDT, P. Taylor Goetz < > [email protected]> wrote: > > > > I cleaned up the download page to remove some of the older releases and > added a link to archive.a.o for older releases. I will also clean up dist > as requested by infra. > > > > While I’m at it, I’ll clean up the javadoc so we only include javadoc > for releases on the download page. > > > > That should help a little bit, but I agree that the publishing process > is painful and would welcome any improvements. > > > > One option (I haven’t tested yet) might be to simply move the javadoc to > the “publish” directory so it doesn’t get regenerated every time the site > gets published. That would mean the javadoc links won’t work when running > Jekyll locally, but I think it’s a fair trade off. > > > > -Taylor > > > >> On Aug 1, 2017, at 9:39 AM, Bobby Evans <[email protected]> > wrote: > >> > >> Rebuilding everything each time is sadly necessary as currently the > header/footer for all of the content is inline in each page. So if we add > a new release every page changes. To fix this we would have to change the > header to dynamically include the HTML from another file that gets updated > on it's own. > >> We might also want to think about rearranging things a bit, and reduce > the number of releases that we have on the site. Do we really need both > 0.9.6 and 0.9.7, or 0.10.0 through 0.10.2. Maybe there is a way to archive > some of these so they are a part of the final site, but are not generated > each time? (probably would need the header change at a minimum to work) > >> > >> > >> - Bobby > >> > >> > >> On Tuesday, August 1, 2017, 6:01:03 AM CDT, Jungtaek Lim < > [email protected]> wrote: > >> > >> I found I forgot to build website with "-d publish/" parameter. Now it > >> reduced to 1347.585 secs but that is still way too long > >> > >> I've done some tests on building website ('jekyll build -d publish/ > >> --profile'): > >> > >> 1. as it is : 1347.585 secs > >> 2. excluding 'releases' directories : 2.38 secs > >> 3. excluding 'releases' directories, and including '2.0.0-SNAPSHOT' > >> directory of releases : 45 secs > >> > >> The build time is not stable but you can see how much the difference > is. If > >> we can separate building doc for each release, that should be best and > it > >> should reduce the build time greatly. > >> > >> If we can't separate building doc, we may want to take alternative > >> approach: reducing maintaining releases. You can imagine that if we keep > >> adding docs for new releases in website repo it should increase overall > >> build time. I guess we may be better to provide only the last version of > >> version lines: 0.9.7, 0.10.2, 1.0.4, 1.1.0 (will be 1.1.1 soon), > >> 2.0.0-SNAPSHOT, total 5 releases. If we respect semantic versioning, > major > >> changes shouldn't be introduced in bug-fix releases so don't need to > >> maintain docs separately. > >> > >> I would like to gather opinions around this along with moving website to > >> git. Looking forward to hear others opinions. > >> > >> Thanks, > >> Jungtaek Lim (HeartSaVioR) > >> > >> 2017년 8월 1일 (화) 오전 7:44, Jungtaek Lim <[email protected]>님이 작성: > >> > >>> Also found that we don't expose 1.0.4 in documentation dropdown and > 1.0.4 > >>> directory is not created in 'publish/releases' directory. Maybe also > missed > >>> that. > >>> > >>> 2017년 8월 1일 (화) 오전 7:36, Jungtaek Lim <[email protected]>님이 작성: > >>> > >>>> Hi devs, > >>>> > >>>> I'm trying to modify release note on 1.0.4 one of user reported about > >>>> wrong CHANGELOG. And surprisingly, it took about 50 mins to serve the > >>>> website locally. Any hints to reduce the time? 50 mins for only > building > >>>> the website is really annoying and anyone don't want to wait for that > if we > >>>> modify "a" file. > >>>> > >>>> And I found Storm 1.1.0 release note markdown file is missing. Taylor, > >>>> could you add it back to the SVN repo? > >>>> > >>>> Thanks, > >>>> Jungtaek Lim (HeartSaVioR) > >>>> > >
