Closed ulitiy closed 5 years ago
Thanks for reporting this
For those who are trying to make sense of this change:
1PB != 1125899906842620 bytes, 1PB == 1125899906842624 bytes, yes. But filesize is expected to round up the result, e.g. filesize(1048574) == '1 MB' although 1024*1024 == 1048576
Hope this helps those who look for changelog like me.
I hope you would understand the issue and the fix based on the details provided, and the single commit to address the issue. A changelog won't help you reason why something is modified, it's just a subset of the commit log.
https://en.wikipedia.org/wiki/Changelog <--- seriously stop being so entitled with the notion of the changelog already, and either land it or stfu.
https://devhints.io/git-log <-- this is required reading
Without a changelog, the only way to determine if an upgrade is "safe" or not is to look at the commit log, which I was doing. And clearly I failed to understand this change at first look.
I'm not arguing with you whether providing a changelog is a good thing or not, I'm merely giving people (who look for the details of an update, people like me) a better understanding of this issue and that's it, what's so wrong about that? This is what I saw, and how I came to this issue, and it only makes me confused because 1125899906842620 is clearly not equal to 1PB. Your test case is even more confusing (to me at least). So that's why I decided to leave a note to future readers.
Btw, providing a changelog is not that difficult, you may want to look into conventional commits and semantic release
Reading through every commit for every package that is a dependency of a project is not sustainable. I would argue that a changelog is a very good thing. I too came looking for changes and am reading entire threads of the project to see what changed, which is not ideal. @zypA13510 Thanks for your comment - it makes the issue and commit much clearer.
Maintaining a change log is a job of a technical writer. I am not a technical writer. Anyone that feels that one should exist is welcome to spend their time curating the git history to create whatever is deemed ideal.
I see the only way of solving it – very inelegant corner case management.