sloum/bombadillo
sloum
/
bombadillo
5
27
Fork 7
Code Issues 18 Pull Requests 1 Releases 9 Activity

Added DEVELOPING.md to include versioning process steps #127

Manually merged
sloum merged 3 commits from release-process-information into develop 2020-01-23 05:46:25 +00:00
Conversation 2 Commits 3 Files Changed 2 +65 -5
asdf commented 2020-01-08 04:02:29 +00:00
Collaborator
Copy Link

This is intended to fix #108.

It is designed as a reminder, not an exhaustive process document. It also helps to inform new people on the change and release processes.

Not having done the process myself, there are probably some errors. The document would need to be validated.

The issue originally described not wanting to forget how the release process occurs. Maybe there is another way to achieve this. I have had this on my mind for a while now, not being sure this is the right approach, but want to get it completed one way or another.

This is intended to fix #108. It is designed as a reminder, not an exhaustive process document. It also helps to inform new people on the change and release processes. Not having done the process myself, there are probably some errors. The document would need to be validated. The issue originally described not wanting to forget how the release process occurs. Maybe there is another way to achieve this. I have had this on my mind for a while now, not being sure this is the right approach, but want to get it completed one way or another.
asdf added the
non-code
non-functional
documentation
 labels 2020-01-08 04:02:29 +00:00
sloum approved these changes 2020-01-08 05:08:30 +00:00
sloum left a comment
Owner
Copy Link

I think this is really good. It documents the process and our thoughts on the process (you captured mine pretty well). I agree that we do not need to be rulesy or dogmatic about it unless an issue arises that forces that sort of thing, but it is a good guide tot he preferred course of action.

I think this is really good. It documents the process and our thoughts on the process (you captured mine pretty well). I agree that we do not need to be rulesy or dogmatic about it unless an issue arises that forces that sort of thing, but it is a good guide tot he preferred course of action.
DEVELOPING.md
@ -0,0 +63,4 @@
As part of the software release process, any part of the version number may change:
- Urgent changes increment the **patch** number
sloum commented 2020-01-08 05:06:52 +00:00
Owner
Copy Link

In general I have been treating patch version changes as changes that will eventually get to master as part of either a minor version or major version merge, but the patches will be versioned as part of the develop branch (master should not generally have things on it with a patch other than 0, unless there is an error fix or the like).

So patches accrue on develop and are listed on the releases tab (but only as minor releases - since they ahve tags tildegit considers it a release of some sort) so people wanting latest greatest can pull those tags. Once enough patches build up develop will get merged into master and the minor version will be updated and the patch reset to 0.

Major versions are akin to python going from 2 - 3 and will not happen often at all (potentially many years in between).

In general I have been treating patch version changes as changes that will eventually get to master as part of either a minor version or major version merge, but the patches will be versioned as part of the develop branch (master should not generally have things on it with a patch other than 0, unless there is an error fix or the like). So patches accrue on develop and are listed on the releases tab (but only as minor releases - since they ahve tags tildegit considers it a release of some sort) so people wanting latest greatest can pull those tags. Once enough patches build up develop will get merged into master and the minor version will be updated and the patch reset to 0. Major versions are akin to python going from 2 - 3 and will not happen often at all (potentially many years in between).
asdf commented 2020-01-09 02:00:57 +00:00
Author
Collaborator
Copy Link

OK, I think we have the same understanding on this, but the way I've written it makes it seem that new changes merged to develop aren't considered as releases. Is that your impression as well?

The document can be amended to indicate new changes merged to develop are still part of the release process, but are "development releases" (or a different name).

OK, I think we have the same understanding on this, but the way I've written it makes it seem that new changes merged to develop aren't considered as releases. Is that your impression as well? The document can be amended to indicate new changes merged to develop are still part of the release process, but are "development releases" (or a different name).
sloum commented 2020-01-09 03:12:49 +00:00
Owner
Copy Link

I think that is a good call. I would not consider them full releases. Development releases is a good term.

I think that is a good call. I would not consider them full releases. Development releases is a good term.
asdf commented 2020-01-23 02:52:00 +00:00
Author
Collaborator
Copy Link

I've reduced the size of this document now, hopefully focussing on the important parts. If no issues let's merge it in.

I've reduced the size of this document now, hopefully focussing on the important parts. If no issues let's merge it in.
sloum approved these changes 2020-01-23 05:45:09 +00:00
sloum left a comment
Owner
Copy Link

This looks good! Thanks for your work on this :) I think it makes good sense and should be approachable.

This looks good! Thanks for your work on this :) I think it makes good sense and should be approachable.
sloum closed this pull request 2020-01-23 05:46:25 +00:00
sloum commented 2020-01-23 05:50:02 +00:00
Owner
Copy Link

This has been merged in and a release has been created.

This has been merged in and a release has been created.
asdf deleted branch release-process-information 2020-01-28 22:02:50 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
blocked

Needs clarification

  
bug

Something is not working

  
build

Relating to the build process/toolchain

  
documentation

Relates to documentation

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
finger

Relates to the finger module

  
gemini

Relates to the gemini module

  
gopher

Relates to the gopher module

  
help wanted

Need some help

  
http

Relates to the http module

  
in progress

Denotes that a member of the team is actively working on this issue

  
invalid

Something is wrong

  
local

Relates to the local file module

  
needs-info

We do not have enough information for this issue

  
non-code

Does not correpond to code issue

  
non-functional

Code cleanup/refactor

  
non-urgent

Take your time

  
question

A request for comment or open question

  
release

This PR is from develop to master

  
rendering

Relates to visual output

  
suggestion

A suggestion for a feature

  
telnet

Relates to the telnet module

  
terminal

Issues with terminal handling

  
urgent

Handle ASAP

  
wontfix

This won't be fixed

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
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: sloum/bombadillo#127
No description provided.
Delete Branch "release-process-information"

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?