Open btam8703 opened 11 months ago
@dheadrick1618 could you take a look at what I have right now and provide any suggestions? I think semantic versioning is great for a project of this magnitude but the main things I am not sure are the following:
Apologies for getting to this so late.
I dont think it makes sense to have versioning related to the sprints at all, for us at least the sprints are likely much more common than we would be able to push new versions.
I like the idea of having a single document (maybe in the documentation repo) devoted to describing each major, minor, patch release changes.
Great work on referencing the semantic versioning that big software companies seem to like to do. As for the other document it has a lot of great points, but I think we don't need a 'dev' branch because we (I think) should follow a git feature branch style workflow, as it is relatively simple. ( https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow )
I think at this point we just need to define what qualifies as a major, minor, and patch. Could you create a markdown doc in the documentation repo ( https://github.com/AlbertaSat/ex3_documentation ), and from that we can start to discuss how we want to define the different types of 'versions' for our releases there.
Good work :)
Never done anything like this before but gonna take a shot when I have time after midterms:
Versioning practices Software releasing
Where are the AlbertaSat sprint periods? Software releases and release notes should be aligned timewise with those sprints.