dali/bacnet_stack
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updated some of the documentation

Browse Source
This commit is contained in:
Steve Karg
2020-06-19 07:48:06 -05:00
parent ff9697bab4
commit fbef685063
10 changed files with 127 additions and 221 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/README.workflow
+35
View File
@@ -0,0 +1,35 @@
========== BACnet Stack source code management workflow ==========
We are working on what will be 1.0.0 in . Once 1.0.0 is finished,
branch master into a new "bacnet-stack-1.0" branch,
and create a "1.0.0" tag. Work on what will eventually be 1.1.0 continues
in master.
When you come across some bugs in the code, fix them in master.
Then merge the fixes over to the 1.0 branch. You may also get bug
reports for 1.0.0, and fix the bugs in the 1.0 branch, and then merge
them back to master. Sometimes a bug can only be fixed in 1.0 because
it is obsolete in 1.1. It doesn't really matter, the only thing is
you want to make sure that you don't release 1.1.0 with the same bugs
that have been fixed in 1.0 branch. Once you find enough bugs
(or maybe one critical bug), you decide to do a 1.0.1 release.
So you make a tag "1.0.1" from the 1.0 branch, and release the code.
At this point, master sill contains what will be 1.1.0, and
the "1.0.0" branch contains 1.0.1 code. The next time you release an
update to 1.0 branch, it would be 1.0.2.
You can also continue to maintain 1.0 brance if you'd like, porting bug fixes
between all 3 branches (1.0.0, 1.1.0, and master). The important take
away is that for every main version of the software you are maintaining,
you have a branch that contains the latest version of code for that version.
Another use of branches is for features. This is where you branch master
(or one of your release branches) and work on a new feature in isolation.
Once the feature is completed, you merge it back in and remove the branch.
The idea of this is when you're working on something disruptive
(that would hold up or interfere with other people from doing their work),
something experimental (that may not even make it in), or possibly just
something that takes a long time (and you're afraid if it holding up a
1.2.0 release when you're ready to branch 1.2.0 from master), you can do
it in isolation in branch. Generally you keep it up to date with master by
merging changes into it all the time, which makes it easier to re-integrate
(merge back to master) when you're finished.