Please update the cudatext package to scrape for new releases at sourceforge.net/projects/cudatext/files/release/ as release publishing on FossHub was long ago discontinued. Depending on how versatile your web scraper is at recursive path traversal, it may be easier to retrieve the new release version strings from one of:
-
the SourceForge project RSS feed, an oft-overlooked resource that reports all new release files added to a project in reverse chronological order and even includes links that bypass their load balancers so that you don't have to worry about the slow HTTP redirects to some mirror site located God only knows where. Some basic regular expression work should make for easy filtering out only the Windows releases and shunting from among them the betas into the prerelease stream; Alexey is very good about obeying his own rubric for the filenames.
One caveat to be mindful of here though is this is so old school that calling it RSS is extremely charitable. It's more of an example of the way XML was used a generation ago which eventually gave someone the idea to create RSS. In it you will find none of the evolution the format has undergone since the dawn of the Age of Podcasts and I personally believe that it was, in all likelihood, coded by an actual reptilian dinosaur. As such, the links I referenced above that bypass the load balancers, while being very real, are not identified as "enclosure" links as would be done in modern RSS but rather by some other blasted name.
That is just one example of why those feeds have a well-earned reputation for making standard RSS/Atom parsers barf like schoolchildren on a field trip to the local waste treatment facility; better results tend to come from using a good old-fashioned XML parser and grabbing the info you need as it can be found rather than as a reasonable person would expect to find it. All that aside, I still think this is the superior source of truth for updating this package. However, another option could be…
-
cudatext.github.io/download.html, where they are plain text in cells of a table that has had the same structure for years. The drawback here is that only stable versions and not betas are reported and they are not linked to the corresponding directory on SourceForge Files. And lastly, we have…
-
GitHub Releases, which has a very well-known API that can reliably report release versions in reverse chronological order and even distinguish between stable and pre-release versions.
Either way, since unlike the "RSS" feed neither of these last two alternatives provide links to the release archive files themselves, it will be necessary to take those version strings—howsoever identified—and append them to the first SourceForge path cited above as the penultimate segment prior to the release archive filename itself which takes the form:
cudatext-windows-$arch-$version.zip
where $arch is either amd64 for x86_64 builds or i386 for x86 and $version is of course the new four-segment version string. Prerelease archives simply append beta to the version string with no additional separators or other characters.
I hope this information is useful in rehabilitating the state of affairs after nearly four years of failing to track the upstream project; it would be delightful to feel secure relying on this Chocolatey package once again.
Please update the
cudatextpackage to scrape for new releases at sourceforge.net/projects/cudatext/files/release/ as release publishing on FossHub was long ago discontinued. Depending on how versatile your web scraper is at recursive path traversal, it may be easier to retrieve the new release version strings from one of:the SourceForge project RSS feed, an oft-overlooked resource that reports all new release files added to a project in reverse chronological order and even includes links that bypass their load balancers so that you don't have to worry about the slow HTTP redirects to some mirror site located God only knows where. Some basic regular expression work should make for easy filtering out only the Windows releases and shunting from among them the betas into the prerelease stream; Alexey is very good about obeying his own rubric for the filenames.
One caveat to be mindful of here though is this is so old school that calling it RSS is extremely charitable. It's more of an example of the way XML was used a generation ago which eventually gave someone the idea to create RSS. In it you will find none of the evolution the format has undergone since the dawn of the Age of Podcasts and I personally believe that it was, in all likelihood, coded by an actual reptilian dinosaur. As such, the links I referenced above that bypass the load balancers, while being very real, are not identified as "enclosure" links as would be done in modern RSS but rather by some other blasted name.
That is just one example of why those feeds have a well-earned reputation for making standard RSS/Atom parsers barf like schoolchildren on a field trip to the local waste treatment facility; better results tend to come from using a good old-fashioned XML parser and grabbing the info you need as it can be found rather than as a reasonable person would expect to find it. All that aside, I still think this is the superior source of truth for updating this package. However, another option could be…
cudatext.github.io/download.html, where they are plain text in cells of a table that has had the same structure for years. The drawback here is that only stable versions and not betas are reported and they are not linked to the corresponding directory on SourceForge Files. And lastly, we have…
GitHub Releases, which has a very well-known API that can reliably report release versions in reverse chronological order and even distinguish between stable and pre-release versions.
Either way, since unlike the "RSS" feed neither of these last two alternatives provide links to the release archive files themselves, it will be necessary to take those version strings—howsoever identified—and append them to the first SourceForge path cited above as the penultimate segment prior to the release archive filename itself which takes the form:
where
$archis eitheramd64for x86_64 builds ori386for x86 and$versionis of course the new four-segment version string. Prerelease archives simply appendbetato the version string with no additional separators or other characters.I hope this information is useful in rehabilitating the state of affairs after nearly four years of failing to track the upstream project; it would be delightful to feel secure relying on this Chocolatey package once again.