Thanks for the initiative, Aditya Sharma!
I think we should additionally provide SQL migration scripts along with the changes.
As an example: we lately introduced the fromDate as part of the PK in SecurityPermission.
So additionally to the change log you proposed, I would add a migration SQL for the Derby database.
ALTER TABLE SECURITY_PERMISSION ADD FROM_DATE DATETIME;
UPDATE SECURITY_PERMISSION SET FROM_DATE = '2017-01-01 00:00:00.0';
ALTER TABLE SECURITY_PERMISSION DROP PRIMARY_KEY, ADD PRIMARY KEY (PERMISSION_ID, FROM_DATE);
(this might be syntactically incorrect, it's only an example).
I also would like to see every change in order of it's introduction. So the order would not be on the entity level but on the database level.
By changing primary keys and such, relations could also be affected and I think it would make sense to have everything in order, especially for migrations.
In our db changelogs, we also list new seed data as OFBiz load data to prevent missing data which is needed by added or changed funtionality.
In my view, the main use case of a db changelog is to help users keep their database up-to-date without the need to monitor everything themselves and do a migration by trial-and-error so it should be as comprehensive as possible.
As a general rule, I would like to introduce the guideline to provide a changelog along with every database or functionality change affecting the data, latest within the commit. If you take the time to work this out, we should take care to keep it up-to-date in the community.