http://qs321.pair.com?node_id=11146847


in reply to Module Change Log

Ignore it as nobody reads change logs anyway

Addressing this part in isolation, I hope you're joking.

In case not, it is worth stating that clear, complete change logs are highly important. When a new version is released the first question a user might ask is "Why?". It could be a security fix or another type of bug fix or a performance enhancement or a new feature or a removal of previously deprecated functionality/syntax or just typo fixes in POD or any combination thereof. The change log informs the user of whether (given their own individual circumstances) they must, should, might, shouldn't or mustn't upgrade.

If you are writing code yourself which has prerequisites, how do you know which version of those prerequisites your code requires? I often find that my code has casually used some feature of a rapidly-developing module which is not present in older versions. Without a change log there is no simple way to tell which version introduced this feature and therefore which version my code requires.

If you have different versions of a module running on different systems and some versions are reporting errors when others are not, how can you determine the reason if there is no changelog to enumerate the differences?

Good change logs are on the long list of things in IT which nobody really notices when they are there but it suddenly becomes clear how important they are when absent.

🦛

Replies are listed 'Best First'.
Re^2: Module Change Log
by stevieb (Canon) on Sep 13, 2022 at 16:08 UTC
    In case not, it is worth stating that clear, complete change logs are highly important.

    I completely and wholeheartedly agree. In my experience, the effort put into a change log is often representative of the effort put into the software.

[reply]
Re^2: Module Change Log
by Bod (Vicar) on Sep 13, 2022 at 15:17 UTC
    Addressing this part in isolation, I hope you're joking

    I was half joking and half serious.

    The more complex or the more functionality a module has, the more the Change Log is needed. I fully realise that it is important. But, in this case, the module is pretty simple and the change is rather minor, albeit to make it work again. So perhaps a better option would have been ignore it until the next release.

    One file I have left as Module::Starter created it is the README.
    I am not sure there is anything useful I can put in there that isn't already in POD.

    Thoughts of README?

[reply]
[d/l]
[select]

      To my mind, README serves 2 purposes. One is a high-level overview of the dist. With this in mind I will usually include in a README: the current version and release date, a brief description of what the dist does, a list of changes since the last release and the licence and copyright details.

      The other purpose is to tell people new to Perl what to do with the tarball they have just unpacked. So that means including the stuff that Module::Starter has put there already about perl Makefile.PL, etc. and then how to find the more extensive documentation (the POD) which will explain how to use it.

      🦛

[reply]
[d/l]
        I don't remember the details, but the README used to get installed by make install to a nonsensical path, usually overwriting the previously installed README of a different distribution. I'm not aware whether it's been fixed.

        map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom