Another approach is separating release specific docs and common docs. I
found other projects are already doing that, most of them are using root
path as common, and docs/<release_version>/ as release specific. Common
docs still need to provide menu to link the root page of each release docs
indeed.
This approach needs some redesign of docs: that is only blocker for the
approach.
2017년 8월 1일 (화) 오후 10:39, Bobby Evans <ev...@yahoo-inc.com.invalid>님이 작성:
> 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 <
> kabh...@gmail.com> 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 <kabh...@gmail.com>님이 작성:
>
> > 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 <kabh...@gmail.com>님이 작성:
> >
> >> 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)
> >>
> >
