As a developer, I'd like the version change process to be documented for next time #108
Labels
No Label
blocked
bug
build
documentation
duplicate
enhancement
finger
gemini
gopher
help wanted
http
in progress
invalid
local
needs-info
non-code
non-functional
non-urgent
question
release
rendering
suggestion
telnet
terminal
urgent
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sloum/bombadillo#108
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
We will probably forget about some of the detail next time we have to make a release, so I'll document the process somewhere (maybe README.md or DEVELOPING.md ?)
Good idea! I think DEVELOPING would be a good call. That would be a fine place to keep notes of that sort for future use.
Just as a quick note so I dont forget, I have started doing the following:
0f670623bd
Just to clarify, each commit merged in to develop is tagged manually, right? And you're doing this like:
After merging into develop I do the following:
Doing this automatically adds a minor (non-stable) release to the releases page on tildegit.
Whenever we decide we have accumulated enough stuff on develop to represent a minor version (
2.x.0
) we can go from develop to master. For that one I would use the-a
flag and leave a detailed commentary. Then I would go and add a release for that tag on tildegit, which will create astable
release.Some notes on this were added to DEVELOPING.md a while ago.
Since then, the process has been refined further by sloum, but I'm not sure there is much value in expanding this document. It is not an authoritative process map, or a guide for inducting new maintainers. Maybe there isn't really a need for these notes, as sloum does most of this activity.
I'll do a new PR to correct what is incorrect, but let me know if this should go in a different direction.