I would say really please fix it: it is quite a breaking change.
eg currently stack-all uses http://haddock.stackage.org/snapshots.json
Perhaps stack could warning about it in the future?
Also the url in the linked stack documentation is still out of date.
Roger that! I’ll fix up the data at the old URLs.
The next version of stack will use an updated URL. I hope to have the correct URL determined by tomorrow, then @mpilgrem can cut a release.
Hm! That URL is under our control and could probably be (permanently) updated to point to the new data source. I’ll look into that.
The data migration has completed now! That means I can start working on fixing up the old URLs very soon. There were a few errors during the process that I need to understand first, however.
FYI the question I want to answer is whether or not I should stick with stackage-haddock.haskell.org as the hostname to use, or if I should pick a name that reflects the specific use case.
The linked documentation is for the ‘stable’ version of Stack (being 2.15.3), is accurate for that version and includes the interim work-around. The documentation for the ‘latest’ version of Stack (being the master branch of the repository) is at: Configuration (project and global) - The Haskell Tool Stack. The plan of action is this:
What is the reason any URL was changed at all?
GHCup has done this once with the metadata URLs, but:
The existing URL is an s3.amazonaws.com URL that points at a bucket owned by FP Complete. As part of the Stackage handover, the content has moved to a new bucket so that FP Complete can eventually remove theirs. The new bucket isn’t even on S3, so I just assumed there was no way to point the old URL at the new bucket.
@mpilgrem , let’s stick with stackage-haddock.haskell.org/snapshots.json.
haddock.stackage.org
The original issue in this thread should now be resolved. The old URL for snapshots.json should now work for the rest of the transition period. I sync snapshots.json back to the old bucket whenever it gets updated.
Let me know if any other problems come up!
@chreekat, thanks. I plan to release Stack 2.15.5 very soon. @hasufell and I are discussing something unrelated (Stack #6526) which I would like to include in the same bug fix release, but if that causes any significant delay it can wait.
Just out of curiosity, where is the new Stackage data hosted?
It’s on Cloudflare’s R2.
I think Stack new and stack init failing ... missing AWS asset "NoSuchBucket"? is the latest user running into this. This will keep happening, hurting stack’s reputation for reliability.
Is there any way to keep things “just working”, including for stack users who haven’t upgraded ?
Like keep haddock.stack.org/snapshots.json existing or redirecting ?
I assume FP Complete owns stack.org, and would be willing to point haddock.stack.org to stackage-haddock.haskell.org - would that do it ?
Is there any way to keep things “just working”, including for stack users who haven’t upgraded ?
Presumably until the official ending of support for the last version of Stack to use the old FP Complete URL.
(Since searching with haskell stack old version support window isn’t working: how long are older Stack versions supported for?)
In practice, people - newcomers to haskell in particular - will be using older versions of stack approximately forever, just like with cabal-install or any tool. Better if we can avoid breaking the new user experience in this way.
I’m going to presume here that one of the goals of migration is to be completely independent of the “previous system”, just in case it disappeared forever.
So (hypothetically)…if “something happened” to FP Complete, the old URL would be broken permanently: there also goes the “new user experience”. To me, the “middle option” is to keep the old URL around until support of the final pre-migration version of Stack ends: then the old URL can be deleted.
Now if at that time there are still people using pre-migration versions of Stack, then they’re are either very overdue for an upgrade anyway, or they will have to learn how their version of Stack works so they can support it themselves (in much the same way someone using an old version of HBC, NHC, JHC, Hugs, or even Yale Haskell would have to). I doubt very few of them would still be new Haskell users…
I am relatively relaxed about this because I follow the places where many Stack users congregate. In practice, the number of queries that arise because somebody is using an out-of-date version of Stack are relatively infrequent and, in the case of this URL change in particular, rare (so far).
There are a number of places where Stack users are prompted to consider whether or not they are using the latest version of Stack, including in issue templates at Stack’s repository and by the Stack executable itself: Configuration (project and global) - The Haskell Tool Stack. GHCup users are given recommendations if they use ghcup list or GHCup’s text user interface (TUI).
The version history of Stack is readily available online - Version history - The Haskell Tool Stack - and that gives users a visual impression of how out-of-date is their current version of Stack.
Yeah so looks like https://s3.amazonaws.com/haddock.stackage.org/ is indeed finally gone.
So presumably the transition period ended. ;o)
I was optimistically hoping it would stay around much longer:
I am going to scamper now to update Fedora stack’s url.
Yeah there’s nothing we can do about amazonaws.com urls since they’re not under our control. 
The bucket has been deleted now, so people will simply have to update the url (or upgrade stack).
Furthermore, haddock.stackage.org/snapshots.json is now also unreachable. Although that url is under our control, it seems we’re unable to point it to the right place using DNS alone. I can’t make haddock.stackage.org a CNAME for stackage-haddock.haskell.org due to Cloudflare’s security policy (one can’t make a CNAME across CF accounts, which is what would happen here). And the attempt to rewrite the specific URL haddock.stackage.org/snapshots.json to stackage.org/download/snapshots.json seems to have no effect.
There are other things I could try but I don’t have the time right now.