I wanted to open an issue for this to discuss adding semantic versioning for ModEM and to discuss a git branching strategy for ModEM.
ModEM currently does not use a semantic versioning and historical 'releases' have been tagged with information linking them to the old SVN repository. Using semantic versioning would better help users identify the most stable and most stable release.
Likewise, we should discuss choosing a git branching strategy.
Semantic Versioning
Semantic versioning is pretty simple and is the form of: MAJOR.MINOR.PATCH (e.g. 1.0.0).
The above images gives an idea on what each number means.
We will only need to deciede what number to start with and what commit to start with. I suggest we start with '2.0.0.'. I suppose the current ModEM version might not be the 2.0 version, but it would be a good place to start. Likewise there are some mentions of 1.X versions in the commit history.
Perhaps a good candidate for the 2.0.0 release will be after a lot of the open PR's are in (including Anna's spherical change). Perhaps this will in the fall?
Git Branching Strategy
There are a few different Git branching strategies out there, some more applicable to a project such as ours. A good overview can be found at: https://dev.to/karmpatel/git-branching-strategies-a-comprehensive-guide-24kh.
The one consideration we should make when choosing a strategy is that we should choose the easiest 'git' method for everyone to use and understand. If my contract would end the strategy should still be easy to by everyone else.
For a scientific software I think Git Flow is the best option, but I also think Git Flow is a bit too complicated. ModEM might do better with a trunk development style. That way, main serves as the primary place to merge new features. However, for releases we will need to create release branches.
In the trunk development strategy, once we are ready for a new version, we should create a release branche off of main (e.g. release/2.x.x). The release branch will act as a way to test and ensure the release stability across test cases. If bugs are found on the release branch, the fixes will be merged into the release branch. Once ready for release the release branch will be tagged with the release (2.x.x) and then merged back into main.
Importantly, any hot-fixes found will need to propagate their way back into these past releases as a new patch version. For instance, if a very egregious bug is found all the way back several releases, the bug-fix commit should be pulled into each release branch and a the patch version should be incremented. That way, a user using an older release (say 2.0.0) have the option of updating to that specific patch (2.0.1).
Documentation
Whatever method we choose, we should document that method so it's easy to follow and remember.
Release before EMIW??
I was thinking it might be nice to create a nice semantic release version before EMIW, but perhaps this will be too much of a time crunch for this week.
@dong-hao or @akelbert please let me know what your thoughts are!
I wanted to open an issue for this to discuss adding semantic versioning for ModEM and to discuss a git branching strategy for ModEM.
ModEM currently does not use a semantic versioning and historical 'releases' have been tagged with information linking them to the old SVN repository. Using semantic versioning would better help users identify the most stable and most stable release.
Likewise, we should discuss choosing a git branching strategy.
Semantic Versioning
Semantic versioning is pretty simple and is the form of: MAJOR.MINOR.PATCH (e.g. 1.0.0).
The above images gives an idea on what each number means.
We will only need to deciede what number to start with and what commit to start with. I suggest we start with '2.0.0.'. I suppose the current ModEM version might not be the 2.0 version, but it would be a good place to start. Likewise there are some mentions of 1.X versions in the commit history.
Perhaps a good candidate for the 2.0.0 release will be after a lot of the open PR's are in (including Anna's spherical change). Perhaps this will in the fall?
Git Branching Strategy
There are a few different Git branching strategies out there, some more applicable to a project such as ours. A good overview can be found at: https://dev.to/karmpatel/git-branching-strategies-a-comprehensive-guide-24kh.
The one consideration we should make when choosing a strategy is that we should choose the easiest 'git' method for everyone to use and understand. If my contract would end the strategy should still be easy to by everyone else.
For a scientific software I think Git Flow is the best option, but I also think Git Flow is a bit too complicated. ModEM might do better with a trunk development style. That way,
mainserves as the primary place to merge new features. However, for releases we will need to create release branches.In the trunk development strategy, once we are ready for a new version, we should create a release branche off of main (e.g. release/2.x.x). The release branch will act as a way to test and ensure the release stability across test cases. If bugs are found on the release branch, the fixes will be merged into the release branch. Once ready for release the release branch will be tagged with the release (2.x.x) and then merged back into main.
Importantly, any hot-fixes found will need to propagate their way back into these past releases as a new patch version. For instance, if a very egregious bug is found all the way back several releases, the bug-fix commit should be pulled into each release branch and a the patch version should be incremented. That way, a user using an older release (say 2.0.0) have the option of updating to that specific patch (2.0.1).
Documentation
Whatever method we choose, we should document that method so it's easy to follow and remember.
Release before EMIW??
I was thinking it might be nice to create a nice semantic release version before EMIW, but perhaps this will be too much of a time crunch for this week.
@dong-hao or @akelbert please let me know what your thoughts are!