More invasive code cleanup?
Tõivo Leedjärv <[email protected]> Wed, 3 Feb 2021 12:47:33 +0100
| Newsgroups | gmane.network.unison.devel |
|---|---|
| Message-ID | <CAALvpZSGphR2C-YyxsCF48FVq_e7YO=89GUe-LS3HgQU=vPTBQ@mail.gmail.com> |
Eventually version compatibility will be broken (for example, when switching to a more stable protocol). When version compatibility is going to be broken, what is the appetite for other more invasive changes? I would like to get opinions and arguments. I am thinking of several code cleanup and maintenance changes, not all of which break version compatibility, that can be more invasive and need more preparation, review and testing. Just as an example, from the top of my head: - Removing CTimeStamp (which has long not been used) -> changes archive format - system/system_win* seems to be nearly (or completely) obsolete with newer OCaml versions and might be removed. Once that is gone, all system/* becomes obsolete? - In several places in code you find FIXME and TODO markers - Sometimes you find comments like (*FIX: remove when Unison version > 2.40 *) - There is some code for functions that are now covered by Stdlib (I assume the code is in Unison tree because it was not available in earlier versions of OCaml) Much of this can make the code smaller and easier to maintain in future. Some could fix long-standing issues. None would bring in new external dependencies. Is there readyness to review and test? Or is the wider opinion to leave the code alone as much as possible and only maintain it to keep it running with newer OCaml and OS versions? -- Toivo