Home / What is new in v3.2?

I am testing 3.2, but what is new?
/Fim W.

At this point not much.

Sumatra is an old C++ code base and there’s been a lot of advancements in C++ so I’m occasionally doing internal refactorings. But there’s nothing visible to the user that is worth talking about.

There is no roadmap.

is it possible to commit version bumps?
so people could track changes independently.

I don’t understand what you mean by “commit version bumps”.

@kjk

I think the comment from @Xashyar may be referencing the fact that any minor build only shows 3.2 on help about thus there is no easy way to tell one from another.

On a personal level I do not clearly understand the direct inter-relationship with the minor numbering of say a pre-release with respect to number of commit identities since the previous one, it does not appear to be 1 - 1.

For reasons that had to do with svn -> github transition, pre-release version is 1000 + number of commits (see https://github.com/sumatrapdfreader/sumatrapdf/blob/master/tools/build/main.go#L138)

@kjk @GitHubRulesOK

What I mean is that if you look through the commits, you can’t see the corresponding changes of each (pre)release.

This is for example how it’s usually handled in the Signal repos, i think it’s a pretty usual routine.

I don’t understand your concerns. To me it would be enough to add build number to the version number in Product Version and File Version provided by MS VC compiler, for example 3.2.0.11040 or 3.2.11040 rather than just 3.2.0. AFAIK compiler can be configured to do it automatically. There may be also text description added (prerelease, beta, portable etc. if needed) in File Version.

Microsoft devs use:

• Product version with build like 11.00.18334.1
• Windows 10 build in File Version like 11.00.18334.1 (WinBuild.160101.0800)
• Timestamp in File Version in older systems like 6.00.2900.5512 (xpsp.080413-2105)

No changes - no need to bump version. Re-release with a new certificate or using reconfigured/patched compiler is also a change, but it’s NOT usual - it’s rather forced because of errors or security reasons.

Do you want to propose another usable solution?

my concern is a very simple one, I wonder why it causes such ambiguity.

how can I tell the difference between version 3.2.11105 and 3.2.11040?

As Krzysztof has pointed out elsewhere that these are only marginal changes that deal with refactoring the old C++. So the change log isn’t provided since 2016 (up until 3.1.2). I think on Github on the other hand the version history should be at least be Identifiable from the Commits section.

There is a slight difference between the commits that affect

main release Added key movement functions H & L
versus
prerelease Lost the ability to use H so moved it to A

also
Main release added new page sizes
but that seems to have
messed up other prerelease printing from command line

such “release” comments could be confusing nes pas

The development is ambiguous. It’s not as simple and straight-forward as you seem to imagine. You shouldn’t expect continuous progress. If you want to use prerelease builds, you should expect unexpected, be ready for for cooperation with devs and for unpleasant surprises.

Prerelease builds have alpha status. They may be buggy or contain experimental, untested features. Some problems may be fixed, some changes may be reverted. What is more, there may be different branches with different changes. Some of them may be directly pulled to the main branch, some other may be ported, but they may also cause regression or there may be typos made when porting changes.

Use GitHub tools more intensively.
How do you find the difference in Wikipedia? Using Wikipedia tools.

I suppose you are aware that short comments about changes in any case show only things most significant to the editors/devs, so they always may be irrelevant from the users’ point of view. If you want to know all the changes and decide what is relevant you should read diffs on your own.

If you don’t like detective work, don’t start experiments with prerelease builds. If you like it, help devs to make better software, f.e. prepare list of observed changes (for better or for worse) important to you (and explain why they’re important).

I have noticed a new thing. Now SumatraPDF portable (at least the current pre-release 11105) creates a folder SumatraPDF in C:\Users\MYNAME\AppData\Local and puts some file unrar64.dll there. I like very much the behavior of 3.1.2 portable which always stores its files and settings in its own folder and never leaves traces outside. Is it a bug or a special new behavior?

@kjk I can confirm this portable misbehaviour of unpacking to alternating named directories such as

C:\Users…\AppData\Local\SumatraPDF\extracted\73ccdb0cbc8313e85fa8073340343d92
C:\Users…\AppData\Local\SumatraPDF\extracted\f551c6a8db5a2b0cb74d77e04d756594

Oddly running 32 bit deletes the 64bit folder and visa versa thus causing potential failure due to loss however one is always left behind which is also undesirable.

Expected location is at worst both unpacked to %temp% thus allowing for later cleaning
Better yet both to be unloaded in the same directory as SumatraPDF.exe so it can work portably

I don’t know if it’s a deliberate change but I agree that for the portable versions this is undesirable behavior. Please fix this @kjk so that the portable versions are self-contained in their own dir as before.

When is the new version coming out ?

The latest SumatraPDF-prerelease-11300-64.exe still behaves in that non-portable way: extracts its unrar64.dll to the user’s \AppData\Local folder. Is it possible to fix, please?

@drkobrin this has officially been raised as an issue with @kjk at https://github.com/sumatrapdfreader/sumatrapdf/issues/1116 however you may see there are several higher priority issues to be addressed in current build first.

Given the recent flurry of activity Sumatra’s codebase is witnessing, I hope this issue of loss of portability is addressed as well and not forgotten once the MuPDF update is complete. Folks downloading the ‘portable’ versions don’t expect something that doesn’t fit the description.

I looked through recent commits on Github but couldn’t understand which belongs to this release.

+The Version’s text is Misaligned:

image1055×494 24.5 KB