369da70f2a
* format: Strip trailing whitespaces
We want to get rid of trailing whitespaces completly as they make just git
noice. Much better to start using automated tools to get rid of them once and
not getting them back again. This way git history will be cleaner and review
easier.
Commit was generated with:
pre-commit run --all-files trailing-whitespace
* format: Files should have exactly one new line end of them
It is good practice that every file has one new line. It is not now days so
mandatory but it also is not nice if file has lot of newlines end of it. We will
use pre-commit which takes automatically care about this so let's fix all.
Commit was generated with:
pre-commit run --all-files end-of-file-fixer
* format: Convert tabs to spaces
Project mostly use spaces over tabs. When mixing tabs and spaces this usually
makes formatting issues and also when changing those in commits it will make lot
of git noise. We will force spaces most of the time and use pre-commit to fix.
Commit was generated with:
pre-commit run --all-files remove-tabs
---------
Co-authored-by: Kari Argillander <kari.argillander@fidelix.com>
========== 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.