The changelog exists to answer the question, "Who made things this way and when?"
I think we do need changelog entries on everything change that changes things, but those comments aren't useful unless they tell us what changed and what the old and new values are. So, I'm not in favour of filling the changelog with a whole bunch of: myusername - Updated server ['Foo'] with id: 42 But I'd be quite interested in this: myusername - Updated server ['Foo'] with id 42: Changed 'origin' from 'http://foo.example.com' to 'http://bar.example.com'. I think that moves it from being spammy to being useful. Might take a bit of thought to make sure we don't create epic changelog messages when someone creates a whole new object or changes a large number of things, but overall I think it would be very useful. WRT the DSRs, I think that considering them to be Change Logs themselves might work at some point, but it's not quite there yet. I would include the changes to DSRs. On Wed, Mar 21, 2018 at 10:46 AM, Dewayne Richardson <[email protected]> wrote: > IMO, I don't think it's necessary to pollute the Change Log with Delivery > Service Requests (DSRs) comments. I think DSRs are turning out to be the > Change Log for Delivery Services and comments on those are Change Log noise. > > -Dew > > On Wed, Mar 21, 2018 at 10:24 AM, Jeremy Mitchell <[email protected]> > wrote: > >> Currently, every POST (create), PUT (update) or DELETE (delete) TO API >> endpoint (or most of them) create a change log entry. >> >> For example when i PUT /api/cachegroups/4 it creates this CL entry: >> >> myusername - Updated Cachegroup named 'Foo' with id: 57 >> >> Question: In the golang rewrite of the TO API should EVERY POST, PUT >> and DELETE trigger a change log entry? Or should it be optional and >> determine by the developer? >> >> I ask because I'm adding endpoints for create, update and delete of >> delivery service request comments and it feels like too much to create a >> change log entry for that. I'd hate to pollute the change log for minor >> stuff. >> >> To me, it seems like it should be optional and determined by the API >> developer. >> >> Jeremy >>
