> On Feb. 9, 2018, 6:02 p.m., Benjamin Bannier wrote:
> > I am wondering whether it wouldn't be simpler to have the site setup just
> > generate output for the currently checked-out version and dump that into
> > some version-specific output folder. We could then have some CI setup
> > execute this for the different tags or branches we care about. This
> > wouldn't only simplify the site setup, but probably also deal better with
> > e.g., changed requirements to the base system (e.g., needed to build
> > binaries generating the endpoint documentation) which are currently not
> > managed in the rake file.
> >
> > One difficulty with that approach would be to determine under what branch
> > we are actually working on. My guess is that we wouldn't want to update to
> > documentation of 1.3.0 until we have tagged a 1.3.0 version, so we'd likely
> > build documentation for the n-latest tags. The `HEAD` of `master` is more
> > tricky as it would change more frequently and not directly have a release
> > tag as parent (these live on release branches) making it harder to work
> > with say `git-describe`. Maybe we could parse this from source, e.g.,
> > `MESOS_VERSION` in `include/mesos/version.hpp`.
> >
> > The other difficulty might be that we might move a lot of site-generation
> > setup out of the repo into e.g., Jenkins config. There are probably ways to
> > work around that, but I haven't thought that through.
>
> Tim Anderegg wrote:
> I'm not familiar with how Jenkins is configured and used here, but your
> approach could be simpler depending on how complex the CI build setup is.
> This patch would remain mostly the same, except lines 68-89 of the Rakefile
> could be removed and the git dependency would no longer be necessary. The
> version could then be fed in by Jenkins, which would probably be
> easier/simpler than trying to programmatically determine the version. Right
> now "master" just translates to "latest" in the patch as-is.
>
> I saw putting everything in the Rakefile as the most straightforward
> approach, since it allows the correct versions to generate docs for to be
> determined programmatically, avoiding the difficulty you mentioned above.
> However, it does require generating all documentation for all versions on
> each build, and significant changes to the build process or documentation
> process down the road might make it difficult to maintain a
> backwards-compatible approach (e.g. I currently disable doc generation for
> the oldest dozen tags or so which don't have the same documentation setup, or
> any documentation at all).