I used to do this in the dark days before I learned git and it was terrible because I updated it every few "work sessions" and skipped half of the things I did. This was a process issue, not with the idea itself though.
I think there's a place for something like this, as information is scattered so wide. You have commits on feature branches that might be descriptive, but they're often squashed and you lose context. There's issues and stories in your task tracker of choice but those cards get migrated through the various states of completion before being archived and you all move on. Basically we generate lots of information as we move forward but that information isn't inclined to move with us.
It requires a little bit of upkeep but for providing a running record of high level, meaningful changes but it sounds useful. This is about features, not implementation details. I think it should go like this:
You create the CHANGELOG.md file, linking to it from your README.
Start working on your feature branch, making commits as you go.
Each feature that's deployed to an environment, dev, stage or production, gets an entry in this CHANGELOG.md file. Preferably with a link to the issue that spawned it.
This file continues to grow and it provides a quick reference point for what's been happening in the project recently.
This isn't a perfect idea but I think there's merit in something like this. It's also accessible to people other than developers. You don't need to traverse a git commit graph to catch up on what's been happening.
Totally agree about issues in the issue tracker being lost over time. Once issues leave the kanban board I never see them again. Going back through the commit history is fine if you are looking for a specific commit or when a specific file changed but when you are just trying to catch up on anything that is actually critically relevant to how you approach a new feature it's not always clear what is actually useful and what is just noise.
I see it as not a comprehensive list of every single feature that has been completed on the project but more of a living readme.md. It's a place where a developer can go to see what technical points have changed that they may find useful. This may or may not be tied to an issue within your issue tracker.
Another few examples: - We switched to user token flow from app token flow so we get access to user endpoints, this includes adding user auth/login interface - Moved storage to AWS bucket so we don't use /storage anymore, see uploadController.php for example of how it's used - Started using Redis for session management due to load balancer being implemented
These are things which you could decipher from the commit history but this is a much more easily digestible format for only stuff that actually may require a developer to change their approach when adding features or refactoring code.
The more I think about it the more I don't think it's wise to enforce it for every feature as some features are trivial enough that they won't effect a developers approach. For instance adding a new route to a simple page may not really change a developers approach to any new features so not really necessary to go into the changelog.md
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I used to do this in the dark days before I learned git and it was terrible because I updated it every few "work sessions" and skipped half of the things I did. This was a process issue, not with the idea itself though.
I think there's a place for something like this, as information is scattered so wide. You have commits on feature branches that might be descriptive, but they're often squashed and you lose context. There's issues and stories in your task tracker of choice but those cards get migrated through the various states of completion before being archived and you all move on. Basically we generate lots of information as we move forward but that information isn't inclined to move with us.
It requires a little bit of upkeep but for providing a running record of high level, meaningful changes but it sounds useful. This is about features, not implementation details. I think it should go like this:
This isn't a perfect idea but I think there's merit in something like this. It's also accessible to people other than developers. You don't need to traverse a git commit graph to catch up on what's been happening.
Totally agree about issues in the issue tracker being lost over time. Once issues leave the kanban board I never see them again. Going back through the commit history is fine if you are looking for a specific commit or when a specific file changed but when you are just trying to catch up on anything that is actually critically relevant to how you approach a new feature it's not always clear what is actually useful and what is just noise.
I see it as not a comprehensive list of every single feature that has been completed on the project but more of a living readme.md. It's a place where a developer can go to see what technical points have changed that they may find useful. This may or may not be tied to an issue within your issue tracker.
Another few examples:
- We switched to user token flow from app token flow so we get access to user endpoints, this includes adding user auth/login interface- Moved storage to AWS bucket so we don't use /storage anymore, see uploadController.php for example of how it's used- Started using Redis for session management due to load balancer being implementedThese are things which you could decipher from the commit history but this is a much more easily digestible format for only stuff that actually may require a developer to change their approach when adding features or refactoring code.
The more I think about it the more I don't think it's wise to enforce it for every feature as some features are trivial enough that they won't effect a developers approach. For instance adding a new route to a simple page may not really change a developers approach to any new features so not really necessary to go into the changelog.md