Steve Karg
36 lines
2.1 KiB
XML
36 lines
2.1 KiB
XML
========== 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.
|