proposal for dev logs

[onur-ozkan]

The way we'r listing contributions in release PRs like in #1576 is very complicated because each developer needs to dig the comment history between mm2.1 and dev branch.

Sometimes we directly push into mm2.1 for things like hotfixes which causes a lot of complications. For example, I checked the last commit on mm2.1, and then write my contribution logs on atomicDEX-API, however, the PR even includes whole tendermint protocol integration & transaction history implementation. It's because I started writing my contribution logs based on the latest commit of mm2.1.

Here is a better solution(imo), each contribution we make on dev branch, we can write log files like in this PR. Log filename is basically summirazed version of what we did, and it contains detailed explanations if needed. It can also contain name of the contributor at bottom.

This is also quite good for future development/analysis. We can parse this data and show the informations in some proper UI screen when we want to.

[ca333]

The way we'r listing contributions in release PRs like in #1576 is very complicated because each developer needs to dig the comment history between mm2.1 and dev branch

are you rethinking this one?

additional input: to further simplify things we can also have this in one chronological "dev.log" file so each contribution is just logged with a date/sprint and based on this we can very easily extract change-logs from this "dev.log" file - can also rotate once certain size is reached, etc.

[onur-ozkan]

This is implemented with #1666

[onur-ozkan]

additional input: to further simplify things we can also have this in one chronological "dev.log" file so each contribution is just logged with a date/sprint and based on this we can very easily extract change-logs from this "dev.log" file - can also rotate once certain size is reached, etc.

It will be probably easier to parse but harder to manually read. It's a great idea, but this proposal target is to make things easier for manually reading in the source tree.

[ca333]

additional input: to further simplify things we can also have this in one chronological "dev.log" file so each contribution is just logged with a date/sprint and based on this we can very easily extract change-logs from this "dev.log" file - can also rotate once certain size is reached, etc.

It will be probably easier to parse but harder to manually read. It's a great idea, but this proposal target is to make things easier for manually reading in the source tree.

The proposed structure is nice in terms of precision and coverage, i agree - however, it is not scalable without explicit indexing (which single dev.log file would provide/gimmick) thus I suggest the additional "living" dev.log file with a chronological structure which will allow us to quickly read / index the dev logs. Take the following example format where devs could ctrl+f to the desired position - and from there they know which sub-dir/log-file to look for.

v1.1.0-beta <log date>
features:
enhancements/fixes:
breaking changes:

v1.0.2-beta <log date>
features:
enhancements/fixes:
breaking changes:

v1.0.1-beta <log date>
features:
enhancements/fixes:
breaking changes:

v1.0.0-beta <log date / mmddyy>
features:
enhancements/fixes:
breaking changes:

Key objective of this additional "living unified dev.log file" is to provide a index as otherwise the dev log proposal from 532da09 will lead to a massive & complex sub dir structure after some time / few sprints which will likely make it hard to navigate inside. Furthermore this uni dev.log will allow us trivial change-log extraction (top section always most recent changes, etc. so not even scroll requirement - just open 1 file, etc.). Each sprint we just bump version and every dev adds bullet-points of whats happening. Can be done e.g. each time dev adds full dev-log. I sense this would be a significant enhancement to the dev logs.

EDIT: proposed it in #1680 and changed naming to "change.log"

[onur-ozkan]

Yeah we can definetly improve to this