With the very greatest respect guys, very few folk understand this - me included
Can someone create a page that says Windows users download this XXX and follow these instructions.
Ditto for Linux.
I understand Mac might be problematic, but a link to HIRAMs last build would be handy.
I get loads of questions over this on my YouTube channel, and it would be cool if there was a 'one link covers all page that I could send everyone to.
Iād do it myself - if I could understand the above, but I donāt so I canāt
For the above executables: If thereās dev in the name they are the, somewhat latests, development version. The ones without are the official stable version.
There are no MacOS/OSX files on the page shown.
Some have .sha256sum attached to the end. Those are checksums files and can be used to verify the executable one downloads.
The rest of the files can be ignored if all one is looking for are out-of-the-box, ready to go executables.
Silly me, I was obviously not explicit enough Jaques - apologies!
Windows Nightly DEV build [click here] download, and follow these instructions. Linux Nightly DEV build [click here] download, and follow these instructions.
HIRAMs Mac build is what I would call a snapshot of the nightly build from a few weeks ago Jaques, but a simple link to it would be far easier for folk to get at than scrolling down a thread on the forum.
I myself am a little loathe to give out download links in case I get them wrong!
Iām just a user that compiles from dev but I think thereās an argument for dowloading dev builds not being to easy. They are usually stable but unless you can figure out which link to choose you are unlikely to be able to recover from and help debugging the issues arising from running unreleased software.
Assuming you are not talking about building RawTherapee from source for the moment.
For Linux thereās this appimage quickstarter page and if I have it correctly you want something like that (sans video) and the equivalent version of that for MacOS/OSX and Windows. All laid out in a bit more streamlined way (not a bare folder + files as shown in your first post).
EDIT:
If you are talking about building from source. What is wrong with this page:
I think the problem is that nobody wants to update the Dev build link every few days. If you can not figure out which Dev build, you should just use the stable build, for which there are direct links on the website.
Maybe thereās a solution for an automatic update of dev links: creating each system build the same as it is currently done, but as a last step (with the building script), clone the newly created build, rename the clone to Ā«whateverOS_latest_dev_buildĀ» and replace the file with the same name if it exists.
This way we still have the build system with proper naming (OS, commit, system) and always an extra file which will be the latest dev build. So just point to this file and thatās it.
I have to agree with what @paperdigits mentions. It isnāt all that hard to make a page that has a few links, pointers and tips. But after thinking about that for a bit I realized that this needs to be kept up-to-date, and assuming that the nightly builds get going again, this needs to be done very regularly. Maybe I can come up with a way to automate it, no promises though.
There is an underlying issue here, one that is already being discussed again on GitHub: When and how RawTherapee is going forward. If newer, stable versions are released more often users wouldnāt look at your (Andyās) videos and drool with what is already possible. This is a bit of a hot issue at the moment so: Iām not stirring the pot here, just stating facts.
Anyway: I think, with hindsight, that my first reply to this topic was rather on topic in explaining which files are relevant for those that are unsure. Mica addressed the which one to choose issue. I donāt think adding a elaborate how-to for those people that do not know what to do with an dmg, exe or appimage (where to move it to, how to make it executable etc) is really wanted. Any search-engine can answer those issues.
Time will tell if itās been a good idea or notā¦
As I have already posted, itās very easy to do, uncomplicated, doesnāt break anything and may solve a few problems (one of them would be the link updating problem).
It is not only wanted. If thereās any interest at all in offering the users all the hard work that has been done after a year and a half since the latest release, it is currently a real problem. A lot of things have changed and perhaps people is willing to use them right now, not who knows when the next release will be launched.
The side effects shouldnāt be that bad. At least in my opinion.
And donāt forget thereās people working hard making all those changes visible to plain users.
All this argument can be seen as the need of an urgent Ā«patchĀ» to solve a problem right now, and then we will see how the Ā«bugĀ» is properly fixed.
A pretty common approach Iāve seen is that the CI system updates a symlink from ādev-latestā to the latest dev build for a given platform once the build completes. Point the website at the symlink.
Of course, thereās the gigantic can of worms of having dev builds being too accessible and people complaining that one of their edits got wrecked by an update (generally youāre safe from that for non-dev builds but a dev build can break compatibility with a previous dev build)
You just spared me some workā¦ Thanks and this might indeed help some people to get going with the new goodies!
I do agree that the hard work that has been done in the last year and a half needs to be available to people, it is more then worth it.
Iām not all that sure how far we need to go with the hand-holding though. Developers have better things to do then troubleshoot users that canāt do some OS related stuff where the solutions can easily be found on-line via a search-engine.
Anyway: Thanks you for setting this up so swiftly!
Yes, that was one of the side effects I was referring to. Iām well aware of that.
And thatās why I say that this will be a patch, a temporary solution. I prefer the third level release option (v.5.9.3), but while this solution is accepted (or any other), we have to do something to show how good RT currently is.
And whenever a better solution comes, that Rawpedia page can be removed. Not a problem anymore.
To more or less address the problem about people screaming about losing their edits, @Andy_Astbury1, and anybody talking/writing about dev versions, could stress the importance of not using anything different than a realease version for work/edits that canāt be lost.
What about the possibility of two different release versions similar to what Libreoffice does. One that is very stable, and one that is cutting edge. The cutting edge could be use at your own risk -but more solid than just a nightly. https://www.libreoffice.org/download/download/
The stable ones could be 2 digits (e.g. 5.8) and the cutting edge ones could have 3 digits (5.8.1). The cutting edge version would have a more rapid release cycle, but eventually it would be capped off and more thoroughly tested to become a full 2 digit version.
That would be a possibility, but it would add even more work to the developersā¦ I mean, if the cutting edge is the same as a dev (nightly) build, whatās itās purpose? And if itās not, then it has to be polished even a little bit to make it somehow Ā«betterĀ» than the dev version. So more work for the developersā¦
The difference would be that when a nightly is in a āgood placeā a version can be frozen as a release candidate. Maybe 2 weeks later if no major bugs are found it can be released as a 3 digit version. If major bugs are found, go back to step a. Nightlies, on the other hand could continue to add new experimental features.
Yes, it is more work for the devs, and I fully appreciate that it is 100% volunteer work. But I envision these 3 digit releases happening every few months, whereas 5.9 has been going on for year.
Notwithstanding that we can definitely improve the visibility of the nightly builds, I donāt think it makes a lot of sense to have a more complicated versioning than we have now. The main reason is that this would require us to work differently (read: more rigidly) with regard to feature development, testing, and the way we manage tags/branches. While this may be better, it would also require changing the way people feel comfortable in contributing now. Thatās always easier said than done, unless you have someone willing to teach us the new ways and help enforce the new policyā¦
Edit: personally, I would definitely appreciate a way to roll out patches more easily.
I am, unfortunately, not qualified as a dev. I do, however, use the nightly on a regular basis and have filed several bug reports and have helped test the patches.
We can always use a hand.