-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release management #20
Comments
I've tagged our current master as v0.3.0 - a prerelease. I am down for going through a full cycle, and then tagging the result that as a v1.0.0 for production use. Your timeline works for me |
+1, Our test and release process would also very much appreciate version tagged releases. |
Speaking about release, is there a reason for 0.5.1 not being marked as Latest on GitHub? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Would like to discuss release management for the project.
Currently we use simple incrementing release, but I'd like to have the ability to qualify releases against our test suite and tag them appropriately. Not every release should go through full cycle IMO.
Open to thoughts, etc. If we don't come up with some consensus, I will simply formulate what I think works best and move on by ~Late October, per my current testing plans.
The text was updated successfully, but these errors were encountered: