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