I guess it's a difference of opinion. I don't think redirects are just used because something "moved", they are used for many purposes. Many projects use "current" or "latest" in their URLs and get-along just fine, and it works well because many people want to link to the latest version of the documentation, not a specific version. (This works, because antora will redirect when page names change, so there isn't really a large fear of these links dying in the future)
Canonic URLs that point to "latest" will be harder to do if we set "9_0" (or whatever the version is) to be the end-url instead of "latest". We do need antora for this, because page names can change and we want the canonic URLs to follow that name change. I have a PR that addresses some of the concerns raised, including a button to copy a version specific link to the page: https://github.com/apache/solr/pull/859 It also makes the ref-guide-version selector and page-version selector more prominent, meaning that we likely don't need the current https://solr.apache.org/guide/ page that just links to the versions. We can link straight to the ref guide, and users can easily choose the version they want. - Houston On Thu, May 12, 2022 at 1:18 PM Uwe Schindler <u...@thetaphi.de> wrote: > Hi, > > > > that’s what I said: Antorra should not create links between latest <-> 9.0 > at all. We just need to create an internal rewrite in the htaccess based on > the version number of refguide. That means we just “symlink” (the Apache > httpd way) the latest to 9.0 and on next release to later. > > > > As said before: > > - Add a rewrite so “9.0” pages and “latest” pages refer to same file > in filesystem. On each release the “9_0” is updated, which happens > automatically in the config of Pelican (in the same way we add the > redirects) > - Each page gets a Canonic URL that points to latest. So any search > engine indexing the 9.0 link will save it as “latest”. We also do not need > Antorra for that, this is plain simple configuration with a LocationMatch > and sending the header with link and also a robots tag. > > > > I am against redirecting 9.0 to latest. This is plain wrong. > > > > Uwe > > > > ----- > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > *From:* Gus Heck <gus.h...@gmail.com> > *Sent:* Thursday, May 12, 2022 5:35 PM > *To:* dev@solr.apache.org > *Subject:* Re: Continuing Discussion on the new Ref Guide versioning > strategy > > > > It seems like the simple way to handle /latest/ is with a rewrite rule? > Just update it each release to point to the canonical version based > location as part of each release. Anyone hitting the canonical link > should not get redirected. > > > > On this page: https://solr.apache.org/guide/ change "earlier versions" to > read "specific versions" Include a 9.0, and change the top link to say > "Latest Stable" > > > > I can't see a good reason to redirect ... redirects are for when something > people may have bookmarked previously is moved. 9.0 didn't move to > 'latest'. > > > > There's a suggestion of a permalink button, but presumably that would > point to /9_0/ and thus get redirected. Just get rid of the redirect... > > > > On Thu, May 12, 2022 at 10:34 AM Houston Putman <hous...@apache.org> > wrote: > > *Separating this out into a separate thread from the release announcement.* > > > > Thanks for getting all of that fixed Jan! > > The Guide page is always redirected to the new 9.0 guide, now there's no > way to get to the 8.11 guide anymore by clicking through the webseite. > > > > I'm going to put the version selector in a better place, so it's easier > for users to know that it exists. > > The default place for the antora UI is in the bottom left hand corner, > which is very easy to miss even when you know where it is. > > > > If you browse through the documentation of a specific issue, you stay > there and your browser cache may not suddenly redirect you. This gets a > problem when we release new Solr versions, because browser cache still > redirect 9_0 to latest automatically, especially if it is 301. > > > > Currently there are no 301 redirects (except for mapping from the old > guide pages to the new guide, this is fine). > > All mappings from 9_0 -> latest are 302 redirects. > > > > In that PR we discussed having a button that would give you a > "perma-link", is that still an acceptable option? > > > > Google harvests all pages, but as each file has a "canonic" URL pointing > to latest, Google will forget older versions and only show "latest" links > in search engine. So "new users from Google" will always see latest > documentation. > > > > I could be wrong, but I don't think that antora lets you redirect latest > -> 9_0, but use latest in the "canonic" URL. I think the "canonic" URL will > be the URL you are redirecting to. IMO we don't really want to hack > something if Antora doesn't support it. > > > > Overall I'm not opposed to having "9_0" be shown instead of "latest", but > I do think "latest" is the cleanest option, and we can solve the other > issues independently. > > > > - Houston > > > > On Thu, May 12, 2022 at 10:00 AM Gus Heck <gus.h...@gmail.com> wrote: > > +1 for uwe's suggestion. It should always be possible to refer to a > specific version of the ref guide. > > > > On Thu, May 12, 2022 at 9:44 AM Uwe Schindler <u...@thetaphi.de> wrote: > > Hi Jan, > > thanks for fixing this so quickly. I was able to get the overview page > with all refguides. The problems with those rewrites and the trailing "/" > were caused by a stupidity in htaccess files: RedirectMatch/AliasMatch all > work with absolute paths, while the RewriteEngine has a RewriteBase, which > must be defined for htaccess (and that's "/"). So all rewrite matches must > be without the "/". This is a pain and not easily recognizable, especially > when you change from Redirect to Rewrite mode in config files. > > As discussed yesterday in the PR/issue, I am not really happy to redirect > all "9_0" links to "latest" as this makes bookmarking and creating > persistent links hard (I hope those links are not 301/permanent). My > recommendation would be to follow the ideas in the PR and let links to 9_0 > stay as 9_0 and we just add a rewrite in the server that maps "latest" --> > "9_0" for the the __root__ rewrite. This can be managed by the pelican > code, which has a variable "latest refguide" already. In addition, all HTML > pages of the 9.0 version should have a "canonic" URL pointing to "latest". > This allows both for our users: > > - If you browse through the documentation of a specific issue, you stay > there and your browser cache may not suddenly redirect you. This gets a > problem when we release new Solr versions, because browser cache still > redirect 9_0 to latest automatically, especially if it is 301. > - Google harvests all pages, but as each file has a "canonic" URL pointing > to latest, Google will forget older versions and only show "latest" links > in search engine. So "new users from Google" will always see latest > documentation. > > I think we should have a decission soon how to manage our pages before > browser caches are stuck with wrong redirects (Sift Reload does not help to > get rid of sticky redirects until you clear browser cache). > > Sorry for repeating this here, but on my box, I got really annoyed tis > morning, because I wanted to send a page to a customer and my cache had to > be cleared first to be able to access pages correctly. > > Uwe > > ----- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: u...@thetaphi.de > > > -----Original Message----- > > From: Jan Høydahl <jan....@cominvent.com> > > Sent: Thursday, May 12, 2022 11:10 AM > > To: dev@solr.apache.org > > Subject: Re: [ANNOUNCE] Apache Solr 9.0.0 released > > > > Congrats to the whole community with the 9.0 release. Big milestone! > > > > Uwe: Thanks for reporting. Both of the issues are now fixed: > > https://solr.apache.org/guide/9_0/ redirects to the new guide > > https://solr.apache.org/guide/ is no longer hijacked by the 9.0 guide :) > > > > I also found another bug - /guide/solr/latest links gave 404 since they > were not > > routed to __root/... That is now fixed. > > > > Routing of "old style latest links" also seems to work, e.g. > > https://solr.apache.org/guide/analysis-screen.html will redirect to the > latest > > version of that page for 9.0. > > > > Another bug Houston and I found yesterday was that RewriteRules from old > > guide did not work. Found the bug, the rule must not start with ^/guide, > but > > ^guide > > So now many more old-style latest links work too, such as > > https://solr.apache.org/guide/a-quick-overview.html > > > > Jan > > > > > 12. mai 2022 kl. 09:38 skrev Uwe Schindler <u...@thetaphi.de>: > > > > > > Hi, > > > > > > thanks for releasing! Great success. I found some minor issues with > website: > > > > > > - The Guide page is always redirected to the new 9.0 guide, now > there's no > > > way to get to the 8.11 guide anymore by clicking through the webseite. > The > > > index.html in the guide folder no longer works. I think we need to > merge the > > > remaining changes? Maybe we need to add a link to the Ref Guide on the > > > download page for all releases, too. > > > - Inside the Solr 9.0 Javadocs on the homepage theres a reference to > the ref > > > guide, but it refers to a 404 not found (we need to add the new URL to > the > > > Markdown page that is used to generate index.html): > > > https://solr.apache.org/docs/9_0_0/index.html (to fix the already > released > > > javadocs, maybe add a redirect) > > > > > > Uwe > > > > > > ----- > > > Uwe Schindler > > > Achterdiek 19, D-28357 Bremen > > > https://www.thetaphi.de > > > eMail: u...@thetaphi.de > > > > > >> -----Original Message----- > > >> From: Jan Høydahl <jan....@cominvent.com> > > >> Sent: Thursday, May 12, 2022 1:41 AM > > >> To: dev@solr.apache.org; us...@solr.apache.org > > >> Subject: [ANNOUNCE] Apache Solr 9.0.0 released > > >> > > >> The Solr PMC is pleased to announce the release of Apache Solr 9.0.0. > > >> > > >> Solr is the popular, blazing fast, open source NoSQL search platform > from > > > the > > >> Apache Solr project. Its major features include powerful full-text > search, > > > hit > > >> highlighting, faceted search, dynamic clustering, database > integration, > > > rich > > >> document handling, and geospatial search. Solr is highly scalable, > > > providing > > >> fault tolerant distributed search and indexing, and powers the search > and > > >> navigation features of many of the world's largest internet sites. > > >> > > >> Solr 9.0.0 is available for immediate download at: > > >> > > >> https://solr.apache.org/downloads.html > > >> > > >> This is a major-version release with breaking changes. The highlights > > > below is > > >> not the full list. Please consult the "Solr Upgrade Notes" when > planning > > > an > > >> upgrade: > > >> > > >> > > > https://solr.apache.org/guide/solr/9_0/upgrade-notes/solr-upgrade- > > notes.html > > >> > > >> Solr 9.0.0 Release Highlights: > > >> > > >> * Minimum Java version supported: Java 11 > > >> * Powered by Lucene 9.0, with numerous small and large improvements, > > such > > >> as smaller index footprint. > > >> > > >> Querying and Indexing > > >> > > >> * Dense Vector "Neural" Search through DenseVectorField fieldType and > K- > > >> Nearest-Neighbor (KNN) Query Parser. > > >> * Admin UI support for SQL Querying. > > >> * New snowball stemmers: Hindi, Indonesian, Nepali, Serbian, Tamil, > and > > >> Yiddish. > > >> * New NorwegianNormalizationFilter. > > >> > > >> Security > > >> > > >> * Certificate Authentication Plugin lets you authenticate with x509 > client > > >> certificates. > > >> * Upgrade to Zookeeper 3.7, allowing for TLS protected ZK > communication. > > >> * All request handlers support security permissions for authorization. > > >> * Solr now runs with the Java security manager enabled by default. > > >> * Solr embedded zookeeper only binds to localhost by default. > > >> * A lot of dependency updates make Solr much more secure. > > >> > > >> Stability and Scalability > > >> > > >> * Rate limiting provides a way to throttle update and search requests > > > based on > > >> usage metrics. > > >> * Task management interface allows declaring tasks as cancellable and > > >> trackable. > > >> * Ability to specify node roles in Solr. This release supports > 'Overseer' > > > and 'Data' > > >> roles. > > >> * Support for distributed processing of cluster state updates and > > > collection API > > >> calls without relying on the Overseer. > > >> > > >> Build and Docker > > >> > > >> * Solr is now built and released independently of Apache Lucene > (separate > > >> Apache projects). > > >> * Build system switched to Gradle from Ant + Ivy. > > >> * Docker image creation is now a part of the Apache Solr Github repo. > > >> * Docker image documentation is now a part of the reference guide. > > >> * Official Docker image upgraded to use JDK17 (by Eclipse Temurin) and > > > ability > > >> to create a local image that is functionally identical to the official > > > one. > > >> > > >> Deprecations and Removals > > >> > > >> * The Data Import Handler (DIH) is an independent project now; it is > no > > > longer > > >> a part of Solr. > > >> * No more support for clusterstate.json and MIGRATESTATE API has been > > >> removed. If your collections use clusterstate.json, please refer to > the > > > Upgrade > > >> Notes. > > >> * Auto scaling framework has been removed. Please refer to the new > Replica > > >> Placement Plugins for alternate options. > > >> * LegacyBM25SimilarityFactory has been removed. > > >> * VelocityResponseWriter is an independent project now; it is no > longer a > > > part > > >> of Solr. This encompasses all previously included /browse and > wt=velocity > > >> examples. > > >> * Legacy SolrCache implementations (LRUCache, LFUCache, FastLRUCache) > > >> have been removed. Users should modify their existing configurations > to > > > use > > >> CaffeineCache instead. > > >> * Cross Data Center Replication has been removed. > > >> * SolrJ clients like HttpSolrClient and LBHttpSolrClient that lacked > HTTP2 > > >> support have been deprecated. The old CloudSolrClient has been > renamed as > > >> CloudLegacySolrClient and deprecated. > > >> * SimpleFSDirectoryFactory is removed in favor of > NIOFSDirectoryFactory. > > >> > > >> Other > > >> > > >> * Contrib modules are now just "modules". You can easily enable > module(s) > > >> through environment variable SOLR_MODULES. > > >> * Features lifted out as separate modules are: HDFS, Hadoop-Auth, SQL, > > >> Scripting, and JWT-Auth. > > >> * The "dist" folder in the release is gone. Module jars are now inside > > > respective > > >> module's lib/ folder. > > >> * SolrJ class CloudSolrClient now supports HTTP2. It has a new > Builder. > > > See > > >> CloudLegacySolrClient for the 8.x version of this class > > >> * Jetty Request log is now enabled by default, i.e. logging every > request. > > >> > > >> Please read CHANGES.txt for a full list of new features, changes and > > > bugfixes: > > >> > > >> https://solr.apache.org/9_0_0/changes/Changes.html > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > >> For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > -- > > http://www.needhamsoftware.com (work) > > http://www.the111shift.com (play) > > > > > -- > > http://www.needhamsoftware.com (work) > > http://www.the111shift.com (play) >
