New major release - RT5

[Beep6581]

This is an umbrella issue for tracking issues which need to be solved so that we can release a new major version. A new release is so overdue that we should strive to get RawTherapee in shape as soon as possible, therefore these issues should not be things we would like solved but things we need solved.

• [x] #1791 Automatically disable Auto-fill when enabling LCP
• [x] #1812 Persistent color picker tool / Lockable Color Picker
• [x] #2568 tunnelMetaData IPTC, XMP and/or Exif?
• [x] #3048 Segmentation fault when switching to next/previous image while curve pipette is enabled
• [x] #3186 Combobox text overflow gtk3
• [x] #3253 Speedup for Flat-Field correction
• [x] #3275 Merge branch rgbcurvesspeedup - Speedup for thumbnail processing
• [x] #3302 dcraw 9.27
• [x] #3304 Race when using same dcp profile with different settings
• [x] #3331 Speedup for dcp processing
• [x] #3334 Update rtexif with latest exiftool data
• [x] #3346 Rework median defines - median speedup
• [x] #3360 Fix Denoise - Median tooltip
• [x] #3367 Segfault when keeping MakerNote and save to tiff16 uncompressed
• [x] #3370 Exif lost when saving compressed tiff from raw on windows builds
• [x] #3406 Soft-proofing branch
• [x] #3443 Fix buffer overflow in dcraw
• [x] #3446 Add support for Gtk+ 3.20 and/or 3.22
• [x] #3465 Clang-tidy
• [x] #3473 CbDL badly interacts with Graduated and Vignetting Filter if CbDL is set to 'before Black-and-White'
• [x] #3474 Segfault on EAHD
• [x] #3480 Crop-guide is wrong when panning image out of preview in Fit-To-Screen mode
• [x] #3483 Gtk+ >=3.20 Comboboxes must not let content overflow
• [x] #3500 Gtk+ >=3.20 Meta tab Exif unusable
• [x] #3506 Navigator/LockableColorPicker does not show correct RGB/HSV for output profile
• [x] #3590 DCP batch settings broken

Code will be astyled before tagging.

[Hombre57]

Is the Gtk3 version using gtk3.18 ?

[sguyader]

I think I'm one of the few still having GTK+ 3.18 in my MSYS2 installation, so I'm building a Windows 64 binary with that GTK version right now. It should be uploaded in an hour or so.

[sguyader]

Here's a Gtk3 build for Win64, made with Gtk+ 3.18: https://filebin.net/cwbf4z2yh5phnivm

Edit: I also included a debug build

[gaaned92]

@Hombre57 I use GTK+ 3.22.7 and it does'nt seem possible to revert to 3.18.

[Hombre57]

Yes, I've tried to revert too without success. Hopefully Sébastien still use Gtk3.18.

[Hombre57]

I find the Gtk3.22 nicer and use it myself, but it has broken GUI elements, or undocumented way of handling things, so I'd recommend to provide a stable version using Gtk3.18.

[sguyader]

@Hombre57 Jean-Christophe, I made a Gtk+ 3.18 build, look the post above André's.

[Beep6581]

I will upload @sguyader 's WinVista builds because they use GTK+ 3.18. We still have no Windows XP builds from the master branch - could someone make those? 5.0 will most likely be the last version for Windows XP.

-- Update Uploaded. Please let me know if you find any references on the website or in RawPedia suggesting to download the latest development version - that needs to be changed to the latest stable version.

[Beep6581]

I will most likely create new tags 5.0-r1-gtk2 and 5.0-r1-gtk3 (r = revision) once #3628 is committed, please don't commit to master or gtk3 until then.

[Floessie]

@Beep6581 Don't you think 5.0-r1-gtk2 is too similar to 5.0-rc1-gtk2 and could be easily mistaken for something older than 5.0-gtk2? I'd expect it to be 5.0.1-gtk2 (but only because I'm used to semver)...

[Beep6581]

Release candidates "rc" and revisions "r" are standard nomenclature. Package maintainers should know this. The problem with "5.0.1" is that the "1" could mean anything, there are plenty of schemes, while "revision 1" means only one thing - same program, something broken in the release was fixed. I favor using the more explicit "revision 1". Our downloads page will only have the fixed "revision" builds of RT 5.0, so no choice for users to get the wrong one.

It's probably time we had a "releases" branch, similar to the model discussed here: http://nvie.com/posts/a-successful-git-branching-model/

Something like this:

• We rename master to something like gtk2_stable and leave it dead.
• We create a new branch master or if we don't want to re-use that word then stable or ship or whatever, see the last point.
• We rename gtk3 to development and it will be perpetually unstable.
• Development will happen in feature branches (pixelshift) and directly in the development branch for smaller direct commits.
• Feature branches will be merged into the development branch when they're ready.
• Every now and then the development branch will be merged into the release branch.
• Bugfixes can be cherry-picked from development into release or made directly in release.
• When the code in release is stable enough, we merge it into master (or stable or ship or whatever), tag it, make tarballs, rejoice.

I think I could handle the merging.

What are your thoughts?

[Hombre57]

Just to avoid confusion : wouldn't it be better to use the branch name release-candidate instead of release ?

[Beep6581]

@Hombre57 I see your point, we could do that. Or we could call it baking, and tag in baked... Just me and Ingo baking bread here? Yes? Oh... :stuck_out_tongue_winking_eye:

[Hombre57]

French translation for those who need it :

Il est probablement temps que nous ayons une branche "releases", similaire au modèle discuté ici : http://nvie.com/posts/a-successful-git-branching-model/

Quelque chose comme cela :

• Nous renommons master en quelque chose comme gtk2_stable et laissons cette branche mourir (nous n'y touchons plus).
• Nous créons une nouvelle branche master, ou si nous ne voulons plus réutiliser ce mot alors stable ou ship ou quoi que ce soit (voir mon dernier point).
• Nous renommons gtk3 en development et il restera perpétuellement instable.
• Les développement interviendront dans des branches dédiées (ex: pixelshift) et directement dans la branche development pour de petits commit directs.
• Les branches dédiées seront fusionnée (merged) dans la branche development quand ils seront prêt.
• De temps en temps la branche development sera fusionnée dans la branche release.
• Les corrections de bug peuvent être appliqués manuellement un à un de development vers release ou (re)faites directement dans release.
• Lorsque le code dans release est assez stable, on le fusionne dans master (ou stable ou ship ou...), on lui ajoute un tag, crée les archives, fait la fête.

Je pense que je peux réaliser la fusion.

Quels sont vos opinions ?

[Hombre57]

@Beep6581 When you say

Bugfixes can be cherry-picked from development into release or made directly in release.

Do you mean that it's possible to redo the fix in release from scratch or only do the fix in release ?

[Beep6581]

@Hombre57 I think bugs should be generally fixed in development (or in the feature branch) and cherry-picked into release if applicable.

[Floessie]

@Beep6581 If we fix a bug in development, are we allowed to cherry-pick it to release or are you the (only) one responsible for the release branch?

[Beep6581]

@Floessie as we tend to discuss everything here before committing I don't think it will be a problem if everyone can commit. I don't want to be solely responsible. I'm only taking this on because I think I can manage, and because by doing so I hope I can free up everyone else to spend time coding not 'gitting', but all help is most welcome.

[Beep6581]

3 days and no objections, but no explicit support either. Do we go ahead and try this new branching scheme?

[Desmis]

For me no problem, that tries nothing has nothing Also if I understand we can not stay like now :)

[Hombre57]

+1 for me to.

[heckflosse]

:+1:

[Beep6581]

Then it's decided.

As for 5.0, happily closing.