Oh no, no, no Jacques - that is way too scary looking for your average photographer!
That would be brilliant I think 
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.
Just a possibility
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.
No it isn’t, and it’s already done.
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.
1 Like
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)
1 Like
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!
1 Like
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.
1 Like
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.
1 Like
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.
1 Like
You should volunteer to help bring your vision to life!
1 Like
@paperdigits is right 
We can always use a hand.
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.
1 Like
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.
Nobody really starts off qualified, you just start doing it, gain the knowledge, then you’re qualified.
2 Likes
Can anyone provide a functioning link & instructions for downloading the dev build?
Which particular dev build are you looking to download?
Jim is looking for Windows PC dev build I think Mike
The most recent builds by @gaaned92 can be found here RTW64NightlyBuilds/ – Keybase.pub
I hope @Morgan_Hardwood is able to fix the automated builds on GitHub soon…