- We have all been here - We are excited to ship the next version - What is in it? - What problems have we solved? - What bugs have we addressed? - What features are we excited about shipping? - How do we communicate these to our end users?
- Cake build script sample for running GitVersion and GitReleaseManager is in the repository
- Fundamental principal - traceability and communication - What version number does it have? - What issues/pull requests are associated with it?
- Single point of truth for information - Both for developers and users - Where we can trace changes associated with the issue - Where we can communicate changes about the issue
- Loaded topic - large discussion - Not going into the details
- A semantic version number expresses the intention of the release - What has changed since the last version
- Final example here has ALL information needed for the purposes of traceability - Most common to have both a "short" version for normal usage, and use the full version as an informational version
- There is no magic bullet here - These tools definitely help in keeping you "honest" about the changes going into a given release - There may be marketing reasons why a certain version number is needed
- Again a loaded topic
- This is the simpler of the two strategies that I am going to show
- This is the more complicated strategy, but also the one that I prefer
- Even though it appears more complicated - Once you break it down, the process is very similar to GitHub Flow - If you squint your eyes a bit!
- Again, there is no magic bullet - Pick the workflow that works for your team - Document it, so that everyone knows what to expect
- .Net Framework - .Net Global Tool - GitHub Action - Doesn't help you decide when a version number need to change
- This couples you to a CI system
- No idea what the version number is
- Started out as a tool from Particular - .Net Framework - .Net Global Tool - GitHub Action