The pages do already have a “Site last generated” date on them at the bottom. It’s specifically worded that way for a reason.
We actually wanted the date the .adoc file was last updated to be in the footer too, but the problem has always been that a static site generator always regenerates all pages every time - so every single page, edited or not, always has the same exact date on it. And, our build works by copying everything under `solr/solr-ref-guide/src` to `solr/build`, so every file really has a create date and last updated date that are always the date you do the build. Basically, the files you see and work with are not actually the same files that get built - we build from copies that are made at build-time. (That’s all why it says “Site last generated” instead of “Last updated”.) I’m not saying there’s no way to add a last updated date for the underlying file, it’s just not obvious how to do it so we skipped it. No problem, though, adding a link to Github - that’s actually kind of a different thing and I’m pretty sure we could do that right now. Cassandra On Sep 19, 2019, 7:07 AM -0500, Anshum Gupta <[email protected]>, wrote: > I agree that we should be able to fix mistakes, my only suggestion was that > those mistakes not be non-trivial. But the more I think about it, the more I > feel convinced about just publishing the updates - however, having a time > stamp on when the guide was last updated would be nice to have. Anything else > would require much more effort and I'm not sure it's worth it. > > > On Wed, Sep 18, 2019 at 2:48 PM Chris Hostetter <[email protected]> > > wrote: > > > > > > : > However Anshum does make a good point that users wouldn't know when > > > : the pages have changed. I think it would be great to have a link on each > > > : ref-guide page that shows the last modified date and links to the > > > : history of that page in github > > > > > > : Perhaps we could instead provide a single HTML page or HTML table as > > > : part of or alongside each guide, showing all commits touching the guide > > > : on that branch after the release. Could probably be baked in as part of > > > : the release script. Using the release date or git hash for the release, > > > > > > Yeah, there are a lot of options we could pursue for generating a > > > "changes" list as part of an automated build process -- but i would > > > consider this idea a "nice to have" feature that shouldn't block moving > > > forward. > > > > > > Given 2 options, I would much rather: > > > a) have the ability to quickly/easily "fix" mistakes/ommisions in > > > "official X.y ref-guide" on our site and have it automatically republish, > > > w/o it being immediately obvious to users that a page may have changed > > > between yesterday and today. > > > ... over ... > > > b) *NOT* being able to re-publish at all just for the sake of users > > > knowing that the (incorrect) content they are reading is consistent > > > between yesterday and today. > > > > > > > > > -Hoss > > > http://www.lucidworks.com/ > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > -- > Anshum Gupta
