GitHub is pretty awesome. It represents just about the perfect balance of everything software developers have been longing for, which sums up why it is popular.
But there is a victim: Changelogs.
Before GitHub, the "changelog" was the mainstay of software releases. It told users of a particular piece of software what was going to go horribly wrong should they upgrade to the latest version. It was the primary form of communication between the developer and users of a given piece of software. It tended to be highly technical but an observant user could identify potentially problematic areas of the software and test those areas in their environment before deploying.
'git' encourages fast, quick changes along the lines of "release early, release often". GitHub, based around git, is therefore directly affected by any side effects of git. Development becomes more of a stream of consciousness rather than blocks of development with set milestones and a lot of projects simply never tag releases as a result. The tendency is to let all changes that would normally be in a changelog to just be the commit log. It is easy, but it is also lazy.
GitHub can improve this situation a LOT by simply introducing a UI that allows for easy changelog creation. Look at the set of commits and commit messages since the last "version" and have a blank textarea to fill in with changelog information. From there, it becomes simple to cherry-pick the things that matter and craft a nice-looking changelog. Since this would be part of the process of creating a ZIP file for the next release version, it would be natural to for the developer to do it. Or, have GitHub store a changelog that is loosely associated with the current branch that allows for filling it in as changes are made and then let GitHub do the actual tagging, simultaneously updating the changelog in the process.
Just a thought anyway.
But there is a victim: Changelogs.
Before GitHub, the "changelog" was the mainstay of software releases. It told users of a particular piece of software what was going to go horribly wrong should they upgrade to the latest version. It was the primary form of communication between the developer and users of a given piece of software. It tended to be highly technical but an observant user could identify potentially problematic areas of the software and test those areas in their environment before deploying.
'git' encourages fast, quick changes along the lines of "release early, release often". GitHub, based around git, is therefore directly affected by any side effects of git. Development becomes more of a stream of consciousness rather than blocks of development with set milestones and a lot of projects simply never tag releases as a result. The tendency is to let all changes that would normally be in a changelog to just be the commit log. It is easy, but it is also lazy.
GitHub can improve this situation a LOT by simply introducing a UI that allows for easy changelog creation. Look at the set of commits and commit messages since the last "version" and have a blank textarea to fill in with changelog information. From there, it becomes simple to cherry-pick the things that matter and craft a nice-looking changelog. Since this would be part of the process of creating a ZIP file for the next release version, it would be natural to for the developer to do it. Or, have GitHub store a changelog that is loosely associated with the current branch that allows for filling it in as changes are made and then let GitHub do the actual tagging, simultaneously updating the changelog in the process.
Just a thought anyway.
Comments
Post a Comment