First of all a big thanks to Cassandra to help coordinate and build our ref guide to make it professional. It really used to be pathetic before you took over
. Yes we need to avoid "creating work" . There should be no need for a ref guide release. +1 for your plan On Thu, Sep 19, 2019 at 11:57 PM Cassandra Targett <casstarg...@gmail.com> wrote: > > 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 <ans...@anshumgupta.net>, 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 <hossman_luc...@fucit.org> > 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: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > > -- > Anshum Gupta -- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
