Hi Jacques - there are the typical comments/questions I get - FYI
Cheers
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.
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.
You should volunteer to help bring your vision to life!
@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.
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.
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ā¦
Like I said just on another thread, folk could use a VM and run the Linux nightly.