You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the earliest versions of TShock, we shipped a changelog file. This was really useful, but somewhat got abandoned when more and more changes were made and nobody was tracking them. An interesting side effect of #924 is that we can start using this as a way to add requirements to contributions, like a changelog.
For example, we could require you to write your own changelog entry for a feature you submit via PR. That way, when someone does go to release the latest version of TShock, they can simply refer to the changelog file that's in the repository for a concise, human readable list of changes. To avoid "ninja" changes slipping in, we won't accept PRs that don't modify the changelog file in some way. This means that releases are a lot faster (instead of requiring hours to dig through and find the real changes from the git log) and that we can provide a historical reference point from release to release going forward.
Keepachangelog has some pretty awesome guidelines that I'd like to refer to if we accept this idea. If we all agree, I can send a PR for the work done so far in the latest version to add the initial changelog file so we can start on the right foot.
Cc. @NyxStudios/tshock
The text was updated successfully, but these errors were encountered:
👍
Sounds much better than having to file a changelog manually every time we want a release (we don't even file it, we just post it in the release thread as text).
In the earliest versions of TShock, we shipped a changelog file. This was really useful, but somewhat got abandoned when more and more changes were made and nobody was tracking them. An interesting side effect of #924 is that we can start using this as a way to add requirements to contributions, like a changelog.
For example, we could require you to write your own changelog entry for a feature you submit via PR. That way, when someone does go to release the latest version of TShock, they can simply refer to the changelog file that's in the repository for a concise, human readable list of changes. To avoid "ninja" changes slipping in, we won't accept PRs that don't modify the changelog file in some way. This means that releases are a lot faster (instead of requiring hours to dig through and find the real changes from the git log) and that we can provide a historical reference point from release to release going forward.
Keepachangelog has some pretty awesome guidelines that I'd like to refer to if we accept this idea. If we all agree, I can send a PR for the work done so far in the latest version to add the initial changelog file so we can start on the right foot.
Cc. @NyxStudios/tshock
The text was updated successfully, but these errors were encountered: