I am testing 3.2, but what is new?
I am testing 3.2, but what is new?
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”.
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)
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 188.8.131.5240 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
- Windows 10 build in File Version like
- Timestamp in File Version in older systems like
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
prerelease Lost the ability to use H so moved it to A
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
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