Release Management #80
Conversation
|
I agree @codingo. This proposal make a lot of sense. I was also aware of the inconsistencies in the versions of SubFinder. I think it's for the best we follow your idea. Just one small change, keep the current version number 1.1 so that we can migrate to v1.2 when we have Finished adding Minor refactors and some features. |
|
I'm ok with that. Let's leave this open to give @Mzack9999 opportunity to comment and provide any suggested changes. Afterwards I'll write up a page on the wiki for release management and whoever merges this request can publish a binary and change list to date. |
|
Further to this, here's an example where I've implemented this: https://github.com/codingo/VHostScan/releases I didn't always publish a new release tag here, but I did always increment the version number on changes and we can make a tavis.io check for that. Once I created a release tag I would review closed pull requests and publish a version history. |
|
It seems like a nice scheme. @codingo or maybe we can do this new release as v1.0 |
Summary
I think as the project has matured we need to take our release tagging more seriously. This project is getting traction and I feel it's important to provide this consistency to allow easier tracking in issues, and for outside integrations.
I propose with merging this pull request we increment to version 1.0, as the first major release point. With subsequent pull requests (that we merge) we then follow the major.minor.patch model.
Major.Minor.Patch Explanation
Basically - if a change is a feature addition following this pull request, the version would become 1.1. If, however, it was a bugfix or minor refactor/linting, the version would change to 1.0.1. With each feature change the patch number resets. So, for example, back to assuming that we release version 1.0.1 and then a new feature is merged, we increment to v1.1, tag the release, and publish a new binary.
Majors are incremented when code vastly differs from a previous point or implementation for outside data sources would change. For example, were we at v1.0 before #51 then we would have made a move to version 2.0 given the significant rewrite. Open to suggestions / feedback on this model though, as I think it's important for it to be intuitive.
Moving forward / the proposal for this pull request
With each release tag we should update the version notes with what changed, and release a new binary. We should also insure the version number is changed in main.go. I'm happy to take care of this if tagged on pull requests, but I think it's something we could manage between the three of us. Thoughts @Mzack9999 @Ice3man543?