Have a proper versioning system

[arihant2math]

Check list

• [x] I have read through the README
• [x] I have the latest version of forgit
• [x] I have searched through the existing issues

Environment info

• OS
  • [x] Linux
  • [x] Mac OS X
  • [x] Windows
  • [x] Others:
• Shell
  • [x] bash
  • [x] zsh
  • [x] fish

Problem / Steps to reproduce

forgit is not versioned. This is a problem because brew (see #194) depends on forgit being versioned.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[carlfriedrich]

I'd like to get this rolling. IMO the only thing to do is start creating tags.

Some questions to discuss @wfxr @cjappl:

1. Is it okay for you if I do this? I am volunteering to maintain the release process, so no work on your side, if you are fine with that. @wfxr If you as the initial creator of forgit want to maintain releases, though, I would be totally fine with that as well.

2. Do you have an opinion on whether to use semantic versioning or calendar versioning? Or do you have another preferred versioning scheme? IMO semantic versioning (major.minor.fix) seems legit for this project. We probably wouldn't ever use the fix revision, though.

3. Should we define a version for the current master already? If you prefer semantic versioning as well, do you think we are on 1.0.0 already? Since forgit is out there in the public and used by lots of people, and we try to keep changes backwards-compatible all the time, I would say yes. So we could define a 1.0.0 version. @wfxr Maybe there is a former version of forgit which you would think of as the first stable version? Or we could just tag the current master with 1.0.0?

Let me know what you think.

[wfxr]

@carlfriedrich

1. Totally fine. And I appreciate all your work for forgit.

2. I think calendar versioning is more appreciate for a project like forgit. We can release new versions periodically without having to think too much about how to define a new version tag or when to do a release. The release processes may be fully automated through the github workflow.

3. This seems not be a problem if we choose calendar versioning?

[cjappl]

All of the above WFM! 🚀

[carlfriedrich]

@wfxr

1. Totally fine. And I appreciate all your work for forgit.

Great, thank you!

2. I think calendar versioning is more appreciate for a project like forgit. We can release new versions periodically without having to think too much about how to define a new version tag or when to do a release. The release processes may be fully automated through the github workflow.

Release automating via GitHub workflow is what I thought of as well, that's definitely a good idea. So do you think we should do monthly releases then? This would mean if anybody pushes a feature on the beginning of a month, we would have to wait until the end of the month for a release.

I personally wouldn't mind creating tags manually everytime we merge something, always increasing the minor number by 1, so that we can release new features quickly. WDYT?

[wfxr]

I personally wouldn't mind creating tags manually everytime we merge something, always increasing the minor number by 1, so that we can release new features quickly. WDYT?

Make sense. The version tag can be like YY.MM.x. Increment x by 1 when we manually release a new version as @carlfriedrich suggested. And reset x to 0 when next month starts (by ci).

[carlfriedrich]

@wfxr That sounds useful. I would propose tagging the current master with 22.11.0 as the initial release then, and I will come up with a GitHub action for automatic monthly releases within the next two weeks.

I see two separate actions here:

1. Tag creation (triggered on every 1st day of the month)

   • Check if current master is newer than latest tag. If yes:
     • Create a release tag

2. Release creation (triggered on new tags)

   • Create a GitHub release
   • Generate a changelog

Anything to add?

[wfxr]

@carlfriedrich Nothing to add. The changelog is a good addition :+1: .

[carlfriedrich]

Done with #246 and #247.