Rawtherapee: 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.

[Beep6581]

I removed "#3264 Merge branch newwavelet" so that RT5 gets out sooner and so that we have more time and less stress to complete and test the newwavelet branch.

[Beep6581]

The gtk3 branch has been well tested using Gtk+ 3.18, and it works generally great except for #3223 - Gtk::FileChooserButton are slow to load. I suggest releasing RT5 with a gtk3-branch dependency requirement on Gtk+ 3.16 - 3.18. We leave 3.20 support for RT-5.1, not only because it would require weeks or months for patching and testing but also because most distros don't even ship it yet. Any objections?

[heckflosse]

One objection: As I'm still building master (gtk2) on windows, I need some help to build gtk3 an windows to avoid outage

[Beep6581]

Making gtk3 the new master does not have to happen when 5.0 is tagged. My suggestion was just about making the RT-5.0 gtk3 branch have Gtk+ 3.16 or 3.18 as a requirement - that is we agree not to support 3.20 until after 5.0 is tagged.

[heckflosse]

Ok, then I agree :+1:

[Hombre57]

@heckflosse If you need help with the gtk3 branch on Windows, just drop me a word by email when you're ready to experiment.

[Hombre57]

So if I understand correctly, the soft-proofing branch is one of the last issue to fix... :-/ I'll have to put the Locked Color Picker patch on hold and finish the Soft-proofing feature first. Do you agree to have a suboptimal soft-proof feature ? i.e. something stable and better than today's situation but still unfinished ?

[Beep6581]

I think that would be fine.
Reasons:

1. It would remove stress from you,
2. It would enable wider testing,
3. Tuning the code to work perfectly for both print proofing and output proofing could take months, this would encourage a small-steps/RERO approach.

[heckflosse]

I added #3048

[innir]

Please apply PR #3443 before releasing RT 5. it fixes a buffer overflow in dcraw.

[heckflosse]

@innir I added it to the checklist above

[heckflosse]

@Hombre57

@heckflosse If you need help with the gtk3 branch on Windows, just drop me a word by email when you're ready to experiment

Problem solved by using different folders for building master and gtk3 :)

[Hombre57]

Great ! Now we have to make the new theme work on Windows again, and I have to finish the soft-proofing branch.

[heckflosse]

@Hombre57 I think we should give priority to rt5 over an optimized softproofing branch. That means, if you agree, I'll look for optimizing softproofing code after rt5 is released. Is that ok?

Ingo

[Hombre57]

@heckflosse Sure, and I'll only do a _first level_ soft-proofing feature, regarding the comments above.

[heckflosse]

@Hombre57 Great :+1:

[heckflosse]

@Hombre57

Now we have to make the new theme work on Windows again

Which is the 'new theme'? I like the 'TooWaBlue' theme using gtk3 branch on Win7. But I don't know whether there are issues using it.

Ingo

[Beep6581]

Morning

Now we have to make the new theme work on Windows again

What do you mean? Gtk+ 3.16 and 3.18 are supported, 3.20 is not. Which version of Gtk+ did you use and which theme are you referring to?

[Floessie]

@Beep6581 @innir Debian Stretch now has GTK 3.22. Will that be supported?

[Beep6581]

@Floessie Yes, that's the plan, but I can't compile it in Gentoo yet because it would break many other programs.

[Floessie]

@Beep6581 Good then! Qemu/KVM to the rescue?

[Beep6581]

That would be one option, but relatively few people have access to 3.22 making it medium priority. My high priority is the RT website, in dire need of dynamite and nails.

[Hombre57]

What do you mean? Gtk+ 3.16 and 3.18 are supported, 3.20 is not. Which version of Gtk+ did you use and which theme are you referring to?

I'm using Gtkmm3.22 as that's the one provided by MSYS2 now, and I'm talking about all the bundled theme.

[innir]

@Floessie Yes, Debian Stretch will ship with GTK+ 3.22. RT in Debian unstable is already built with GTK+ 3.22 and it works fine (from what I see). To be sure to get RT 5 in Debian stretch it should be released latest end of the year.

[Beep6581]

It would be nice if RT5 could support Gtk+ 3.22... Yesterday I compiled the latest Gtk+ available on Gentoo, that's 3.20.9. If 3.22 is compatible with 3.20, then we can kill two birds with one stone.
I want RT5 out very soon, this month. If 3.20/3.22 support doesn't make it into RT5(.0), then by the end of the year we could release a 5.1.

[innir]

@Beep6581 I already built RT with Gtk+ 3.22, it's in Debian unstable so you could give it a try. I didn't see any obvious problems.

[Beep6581]

@innir thank you but I don't use Debian and I make my own builds.

[Beep6581]

TODO when releasing:

• http://rawpedia.rawtherapee.com/How_to_release_RawTherapee
• astyle code
• Replace (c) and (C) with © (or whatever, to keep things consistent. #3445)
• Update versions (4.2?) and dates
• Add links to new forum to About window
• Summarize new features significant to a user instead of a detailed changelog
• Release Notes, add comment about building for Windows from https://github.com/Beep6581/RawTherapee/issues/3544#issuecomment-267606005
• Coverity
• Bulk cleanups with clang-tidy (@Floessie)
  
  
  
  • modernize-use-nullptr
  
  
  • readability-braces-around-statements
  
  
  • modernize-redundant-void-arg
  
  
  • readability-simplify-boolean-expr
  
  
  • misc-redundant-expression
  
  
  • readability-redundant-control-flow
  
  
  • readability-avoid-const-params-in-decls
  
  

[Beep6581]

If anyone has things they'd like to do, or things they'd like me to do, just before releasing RT5, then feel free to make a list or to edit my list above.

[Hombre57]

I'll look at the Gtk3.22 theme ASAP, hopefully before the end of next Sunday. If I can't fix it, then you'll have to release a Gtk3.18 Windows version.

[Beep6581]

@Hombre57 ok, I added #3446 to the list so we don't forget. I was unexpectedly upgraded to Gtk+ 3.20.9 a few days ago.

[sguyader]

@Beep6581 I would like to see #3229 fixed with the next RT release. I think a number of advanced or pro photographers turn to the latest Fujifilm cameras, I think complete support of their raw files would make RT more attractive to them, as RT is now known as one of the best raw developers for X-trans files.

[heckflosse]

@sguyader Hi Sébastien. I already started work at porting the libraw code for compressed xtrans files to rt. But it's a lot of work because it has many dependencies to libraw internals. For that reason I would like to complete it after rt5 is released. @Beep6581 already planned to release 5.1 end of the year. That would fit much better (for me at least) ;-)

[sguyader]

@heckflosse ok Ingo, I had no idea it requires so much work to get the libraw code into RT.

[Beep6581]

Hello

re: https://github.com/Beep6581/RawTherapee/commit/ccd9002c3abc504e3a25b7bbf0489b90b4cf808e#commitcomment-19352462
I like fixes, fixes are good. I'm very glad you guys have been focusing on fixes for so long - RawTherapee is much better off thanks to them.

Generally what one would do at this point is to branch off and make release candidates and then a final release when ready. I could do that, but it would require two branches: a master-rt5 and gtk3-rt5 branch, and then tags in each. A bit messy. But there are only a few of us, and as RT doesn't get new features often anyway, it would be simpler to just agree not to commit anything but fixes for a week or two. Would that work for you? Or do you have strong arguments for branching off?

Committing those cppcheck etc fixes would make it easier to maintain other open branches and patches. I understand there are risks - merging them makes them available to a wider testing audience. Let's do that now, so there is more time for testing and releasing RT5 this month.

[heckflosse]

Merged cppcheck and let it open for further work

[Floessie]

@heckflosse @Beep6581 When and how would you like me to do the clang-tidy bulk changes (if at all)? I could create a temporary branch from master and apply those changes only for testing. If it still works and builds (which I expect), I could do the same after the soft-proofing branch is merged. What do you think?

[Beep6581]

At this point we need all the testing we can get. If the clang-tidy changes are to be part of 5.0, and if they're in good enough shape, then it would be better to merge them into master ASAP so nightly builds become available straight away for testing. If these are the kinds of changes that could cause major problems (for example corrupt parts of images which only occur in one image here and there, making them difficult to discover and trace) then it's better to not include them in 5.0. You decide.

[Floessie]

@Beep6581

If these are the kinds of changes that could cause major problems (for example corrupt parts of images which only occur in one image here and there, making them difficult to discover and trace) then it's better to not include them in 5.0. You decide.

I've confidence in the clang-tidy checks that included in the list. Most of them are about streamlining the code, some of them simplify logic. This could be some kind of a problem, and if they are too invasive, I'll skip them. But I only had positive experience with those checks.

Okay then, I'll prepare a branch ASAP so that you can have a look on what will change and what you like or don't like about it. But if it is merged to master, be aware that it will make merging harder. That's why I suggested doing it ALAP. Basically the same rules apply to your astyle run.

HTH
Flössie

[Beep6581]

@Floessie a branch would be good :+1:

if it is merged to master, be aware that it will make merging harder

@heckflosse @Hombre57 @Desmis please weigh in, as it affects the large number of outstanding patches and branches.

[heckflosse]

No problem with my outstanding work.

[Hombre57]

I'll probably merge the soft-proofing branch tonight, so there will be no issue for me but for you here.

Regarding the other opened branch :

• spot-removal-tool : I'll be able to merge your changes in this branch, there's not much collision with existing code
• gtk3 : can't say, @Beep6581 will handle any merge
• SaveStrategy : stalled branch, sadly, because too much suggestions that can't be satisfied rapidly. It was 95% done IIRC. This branch touch the GUI part mainly. I need to see you changes @Floessie, so I'll see if I can merge w/o too much trouble.
• locallab : @Desmis' branch, this one is a big and active one, despite the fact that we'll open a concurrency branch after the official switch to Gtk3 and the merge of spot-removal-tool branch (that might take some part of the code)
• newwavelet : @Desmis' branch, seem to be stalled too.
• gammadif : @Desmis' stalled branch, because not enough test from the devs. Considering the recent comment from @ellelstone, I think we should keep it alive. It will however be very difficult to update it to the current master.
• cacorrectfix : @heckflosse's branch, don't know the status of this branch.

Adam's _Compress thumbnails_ PR is stalled too. I don't think we can hope for someone to it take over.

I'll tell you my final words about my branches after the analysis of your clang branch @Floessie .

[Beep6581]

I would really like "newwavelet" to make it into 5.1! It had some bugs the last time I tried it, but @Desmis worked on it after that and I haven't had a chance to properly test it since.
"gammadif" I didn't test because I didn't understand what it really did or how to test it. After recent discussions I'm also interested in it.

[Floessie]

@Hombre57 No need to get in a hurry because of me. My plan is to provide you all with a clang-tidy branch to see what will change. This will be a temporary one, which I'll ditch later. When you all and especially @Beep6581 is okay with it, I'll create a new one after all branches for 5.0 have been merged and near the point where @Beep6581 will do his astyle run. Sounds sane?

To ease merging other branches, I could branch them off and apply clang-tidy on them, too. Merging them should then be not so much of a problem. Theoretically, git is smart enough to detect if lines are the same even if they were changed independently.

[Desmis]

For me, you do what you want, there will always a way to fix after, either alone or with the help of someone :)

newwavelet: Unless I am mistaken, Ingo has taken time to examine the code some weeks ago.

gammadif: it is an "old" branch, with more features as it seems

locallab: there are two different things in it, as I have already said.
1) the algorithm itself "U-point type", now from my point of view works correctly (it can probabaly be improved and optimzed!), with similar performance has CN2 or Nik Software, which is to say that there is virtually no need to be trimmed objects, or use masks. Even if we can use.

2) management of multiple points, which faces the problem (dcrop.cc) to place the detection area (hue, ligthness, chroma) outside the preview (actually generate crash or dysfunction). This will be the same problem whatever the "multipoint" method, due to RT pipeline.

:)

[Floessie]

Here is the demo branch. Some remarks:

• readability-braces-around-statements failed with macros. Maybe astyle can help here (uncrustify definitely can).
• readability-avoid-const-params-in-decls found nothing. :+1:
• readability-redundant-control-flow neither. :+1:
• misc-redundant-expression neither. :+1:

HTH
Flössie

[Beep6581]

Hello
How are we with the clang-tidy and >=gtk+-3.20 branches/patches?

[Floessie]

@Beep6581 I have to clean some things up on the clang-tidy branch (for instance dcraw.cc has to be reverted prior to merge) and have very little time this week. I can't promise to finish or recreate it this week, but I'll try to somehow make it.

[Hombre57]

I tried to get RT works with gtk>=3.20, but I'm about to give up. Still on this issue at the moment.

[Hombre57]

That's official : I give up on making RT work with Gtk3.22. I'd recommend to enforce the use of Gtk3.18, since it's the last stable version that RT can use. If you're okay, you should replace >=3.16 by =3.18 on line 229 & 232 of the main cmakefile.

Removing issue #3446 from the blocking issue.

[innir]

@Hombre57 Please don't or at least not for Linux- this will make RT non-installable for almost all Linux users using recent distros. It works here on Debian with GTK+ 3.22 (and a version using GTK+ 3.22 is already in the official Debian repository).

[Floessie]

@Beep6581 @heckflosse I've updated the clang-tidy branch. Please have a look if my merge from master was okay.

[Beep6581]

@Hombre57 I'm looking into it...

Hey @innir I was looking for the Debian RawTherapee package maintainer yesterday, and was surprised to find it was someone I know - you :)
"it works" means it loads, but it looks very bad and unusable, right?

@Floessie compiling...

[innir]

@Beep6581 Yes, always try to make rawtherapee easy to use :) and no, it looks good, I don't see any obvious problems.

[Beep6581]

@innir that's... not possible! Could you show a screenshot of a RT build which uses Gtk+ >=3.20 and looks good?

[Hombre57]

@innir That's interesting. Could you answer the following points :

1. Which precise version of Gtk are you using ? Could you post your AboutThisBuild file please ? And the log of the cmake process too, it'll give use some details on all the versions of the libraries.
2. Don't you have warning message when starting RT ?
3. Do you have the system them selected or one of the custom themes ?

[innir]

Here is a build log for i386: https://buildd.debian.org/status/fetch.php?pkg=rawtherapee&arch=i386&ver=4.2.1241-2&stamp=1475275785

Screenshot: http://i.imgur.com/fbRocGw.jpg

Here is my AboutThisBuild (sorry this is for amd64):

Branch: gtk3
Version: 4.2.1241
Changeset: 4a032e6fa958a1d1ff49ff4bfaf754f09d90dea2
Compiler: cc 6.2.0
Processor: x86_64
System: Linux
Bit depth: 64 bits
Gtkmm: V3.22.0
Build type: Release
Build flags: -g -O2 -fdebug-prefix-map=/build/rawtherapee-4.2.1241=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=c++11 -Wdate-time -D_FORTIFY_SOURCE=2  -std=gnu++11  -Werror=unused-label -fopenmp -Werror=unknown-pragmas -O3 -DNDEBUG
Link flags:  -fPIE -pie -Wl,-z,relro -Wl,-z,now -Wl,--as-needed
OpenMP support: ON
MMAP support: ON

[innir]

@Hombre57:

1. See my last post ;)
2. I get some warning but not many: http://pastebin.com/nWhFuHdC
3. I use the system theme, never tried a cusom om

[Beep6581]

@innir what you're seeing is the problem - hideously large widgets, RT CSS theme not used.

[Hombre57]

...and we shouldn't have any warnings. RT doesn't work with Gtk 3.22 yet (nor 3.20).

[innir]

@Beep6581 @Hombre57 Well, it works - It might not look as pretty as it could. But if you think it should not be shipped, I'm OK with it - should I package the gtk2 version instead?

Debian/Ubuntu/..., Fedora, Arch and all other major Linux distributions have GTK+ >= 3.20 now so there must be some plan for Linux I fear...

[Beep6581]

@innir we're working on it, with no promises...
If we don't manage to fix it, then distros with Gtk+ 3.16-3.18 should have the gtk3 branch, while distros with any other Gtk3 version should have the master branch.

The number of people using Gtk+ 3.20 or higher is far smaller than the number of people using <=3.18

[Floessie]

@Beep6581

The number of people using Gtk+ 3.20 or higher is far smaller than the number of people using <=3.18

Normally, you are the one asking for proof of such statements. :flushed:

Debian/Ubuntu/..., Fedora, Arch and all other major Linux distributions have GTK+ >= 3.20 now so there must be some plan for Linux I fear...

IMHO, this is much more the truth. But fortunately, there is still the master branch.

[Beep6581]

@Floessie I expected that ;) http://distrowatch.com/table.php?distribution=xxx
But good news - Hombre and I have been working on this and we already have a good-looking RT on >=3.20

[heckflosse]

I added #3469

[heckflosse]

I added #3473 and #3474

[Floessie]

@Beep6581 @heckflosse Is it wise to keep adding "feature bugs" (like #3469) to the list? How can we reach a milestone, if that stone is rocking? :wink:

Having RT5 finished by the end of month would be really nice. Well, that's a bit self-serving, as I'm on Debian, and although @innir mentioned there was time until the end of year, I'm sure RT5 integration to Stretch will be easier when done before the transition freeze on 2016-11-05.

@Beep6581 I was looking for the RT 4.2 logo SVG, but cannot find it (rt_logo.svg only has the base logo). Have you already prepared an inkscape SVG for RT5, that could be used for promotions immediately after the release?

[heckflosse]

@Floessie No problem to remove #3469. I just put it there because #3446 is still open and maybe we can solve it too meanwhile.

[heckflosse]

I removed #3469 from blocking

[Beep6581]

I'd like to squeeze #3488 in, as it's small and benign.

[heckflosse]

:+1: for #3488

[Beep6581]

I added:

• #3483 Gtk+ >=3.20 Comboboxes must not let content overflow
• #3500 "Gtk+ >=3.20 Meta tab Exif unusable"

Those are the last things needed for RT5 to be usable with GTK+ >=3.20, after that I'm happy to release.

[Beep6581]

RawTherapee 5 release notes/announcement draft:
https://gist.github.com/Beep6581/731709bf78885b2afea92388ee6ede2a

You can make changes the usual git way - commit and PR. You can also commit on individual lines.

Note: some lines and words will contain links, e.g. "Complete revision history on GitHub" will link to https://github.com/Beep6581/RawTherapee/commits/master

[Beep6581]

Hello @Hombre57
Issue #3483 (combobox can make toolpanel min width far too wide because text is not ellipsized) and #3446 (pre-select correct CSS file, and find out how to change font size) are the only things blocking RT5. I don't want to stress anyone, but myself feel stressed about this, and I'm leaving for Zambia this Sunday for a week. Could you give an indication on how things are looking?

If #3483 looks not-solvable for now, then it would be better to revert the behavior so that the text overflows as it did before, allowing the toolpanel to be shrunk, so that users of not-high resolution screens can at least use RT. What do you think?

[Hombre57]

No particular problem for #3446, can be done rapidly. However #3483 is really complicated, at least for someone that is not used to CellLayout or CellRenderer... I'm okay to revert to the previous state, but will still try to solve it upon time, given the deadline of this Saturday.

[Hombre57]

@Beep6581

Thinking of it again, I remember that RT's GUI is fine for the Gtk3.22 CSS file, but not for 3.18 as @heckflosse said. I don't have that version installed, how can we do ? I can update the 3.18 CSS file, but it's shooting in the dark.

[Beep6581]

@Hombre57 as I undertood it, we agreed to have the RawTherapee.css from gtk3 renamed to RawTherapee_GTK3_316-318.css (using whatever separator you like) and the one from gtk3-bugfix renamed to RawTherapee_GTK3_3.20-3.22.css, and having RawTherapee load the right one dynamically. The original idea was to have package maintainers pick the right one for their build.

What do you mean by updating the 3.18 file? There is no need to touch it, and that would add more delay to the release.

[Hombre57]

@Beep6581 As you know, the look of the GUI can be controlled by the CSS file and from within the code itself, through functions like set_col_spacing, set_row_spacing, etc... I've removed some of them from the code as they are now set in the CSS file as recommended. Furthermore I had to change the object hierarchy in some rare places, and update the way that backgrounds are drawn. All of this require a little checkup of the V3.18 CSS file, but nothing that would take even one week. Unfortunately it doesn't match your agenda.

[Hombre57]

As explained in issue #3545, the very last bug(s) that prevent making an RT5 Release version is due to Gtk3.22 itself. This time I don't think we'll be able to create a workaround, so what's do we do about RT5 now ? Should we wait till it is solved in Gtk or will we release it and force usage of Gtk3.18 ? The problem is that MSYS2, AFAIK, doesn't provide Gtk3.18 anymore, only the broken 3.22 :(, so Windows will only have the Gtk2 version available. Might be better than nothing due to the situation.

[heckflosse]

I'm still using MSYS2 with gtk 3.18

[Hombre57]

Because you didn't updated MSYS2 ? Then it's great, we could provide a Gtk3 build, for Windows at least.

[heckflosse]

Yes, but I would need some help, because in past I only build for my system, no setup etc...

[gaaned92]

builds of @sguyader are done with gtk3.18. So perhaps he could make the RT5 builds with gtk3.18 waiting for a repaired gtk3.22.

[iliasg]

I would like some easy issues fixed in RT5.0

• https://github.com/Beep6581/RawTherapee/issues/3519 fix is ready for commit https://github.com/Beep6581/RawTherapee/issues/3519#issuecomment-264666406
• https://github.com/Beep6581/RawTherapee/issues/3506
• https://github.com/Beep6581/RawTherapee/issues/2729

[Beep6581]

Should we wait till it is solved in Gtk or will we release it and force usage of Gtk3.18 ?

As discussed previously, this is not a good option. If it is a GTK3 bug then it could take a year before it is fixed, a new version of GTK+ is released and some distros pick that version up. Even then, it would only cover some distros. And preventing many people (myself included) from using RawTherapee entirely just because of some UI bug is not something I'd be happy with :) RawTherapee is completely usable even with this bug. All we should do is to recommend that GTK+ 3.18 is used if possible - package maintainers will be notified.

[Hombre57]

@Beep6581

RawTherapee is completely usable even with this bug.

Well, that's a point of view. Yes it's functional, but lots of curves have this problem (RGB, HSV and probably others).

The gtk3 team knows that it's a very well hidden bug, because they had to create a workaround in scrollbars to circumvent it. I'm adding an issue in their tracker.

[Beep6581]

TODO: Mention #3545 and #3525 in release notes or somewhere.

[Hombre57]

Last blocking bugfix committed. ( @Beep6581 @heckflosse ) Please be careful with astyle : if it's very invasive, it may be hard/complex to merge into other branch.

[Hombre57]

@Beep6581 I'm on the verge of finishing the French translation strings, due tomorrow evening. Could you wait my commit before tagging RT5 please ? It would be better to include the finished translation in the initial release IMHO.

[Beep6581]

@Hombre57 sure.

RawTherapee 5 release date is set for Sunday.

[iliasg]

@Hombre57 what about https://github.com/Beep6581/RawTherapee/issues/3506 ?

[Hombre57]

Yes, I'll have a look tonight.

[Beep6581]

Are your whiskies ready?

[Hombre57]

Sorry, Champagne for me ;)

[heckflosse]

Of course :+1:

[Desmis]

No problem for me. 
But with Rhum :)

[Hombre57]

RT5 is out, thanks to everyone involved !

[Beep6581]

Thank you everyone! A great pleasure and honor :)

[Floessie]

:tada: :fireworks: I really had lost my faith in the "this sunday" announcements, but this time you really made it! Thanks @Beep6581 for managing this awesome release and all of you who put time and heart into this wonderful piece of software. :+1:

[gaaned92]

Thanks @Beep6581 and all developpers for this awesome software

W64 Master and gtk3 5.0 stable builds are uploaded here https://drive.google.com/open?id=0B2q9OrgyDEfPS2FpdDAtMVI1RG8
default installation in "program files/rawtherapee"
beware that only one stable version can be installed.
W32 builds to follow
André

[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.