Replies: 2 comments
-
We usually increment the build number when there are changes in the code, mostly to have a point of reference when something goes wrong. When changes are not it the code, it is way less likely that something can go wrong and users will have to report it, so we don't need a point of reference that much and the old build number will do. It does not affect anything else anywhere else. ChangelogHeader.lua simply does not cover such case and prints rubbish. It would be nice to fix it, but such cases are so rare that no one could be bothered. The first entry is correct. |
Beta Was this translation helpful? Give feedback.
-
Thank you. Just wanted to make sure so I don't mess up your changelogs. |
Beta Was this translation helpful? Give feedback.
-
Information
As described below, changes do not always require a build increase. In these cases, should the entry in the changelog file use the previous build number, or omit it?
FarManager/CONTRIBUTING.md
Lines 54 to 59 in 42b1fb1
If the build number is omitted, as shown in the first entry below, the
ChangelogHeader.lua
macro generates the new build number using the time zone offset. In this case, it generated a build number of801
instead of6098
.changelog from 9ec1f71
Question
What should be the correct entry here? 1 or 2?
MZK 28.01.2023 18:41:14 -0800
MZK 28.01.2023 18:41:14 -0800 - build 6097
Beta Was this translation helpful? Give feedback.
All reactions