License

 Software  Comments Off on License
Dec 072015
 

When writing software, at work or at home, you will eventually end up thinking about which license, if any, you should use.
I have been thinking about this for some time, and found this site, http://choosealicense.com/, which was really helpful to me.

I have chosen to go with the MIT license, since it very permissive and simple.
This is how the license text look like.

The MIT License (MIT)

Copyright (c) [year] [fullname]

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

It should be either inserted into the source code file, or added as a LICENSE.txt file in the project.

Branching strategy

 Git, Software  Comments Off on Branching strategy
May 012014
 

This is my branching strategy, which should work well for any development from a single developer to a small team.
The goal for the strategy is to minimize branching, and administrative tasks.
For large team development a completetly different approach is needed.

Here is the strategy described in words:
* Use Master branch as development branch.
* When it is time for a release,
- tag the commit, ex v1.0
- create a branch, ex v1.0
* Continue development on Master branch
* Make corrections/fixes for v1.0 release on branch 1.0
* Merge fixes back to development/master branch (if needed)

Some ascii art to show the workflow

 tag     1.0                             1.1
 ---------*------------------*------------*------------------*-------> Master
           \                /              \                /
            \              /                \ v1.1         /v1.1.1
             \ v1.0       / v1.0.1           -------------*------> 1.1
              -----------*-------> 1.0

Here is a small example

git init
echo "some text" > a.txt
git add a.txt
git commit
echo "some more text" > a.txt
git commit -a
git tag -a v1.0 -m 'version 1.0'
git branch v1.0
git checkout v1.0
echo "third row of text, on new branch" > a.txt
git commit -a
git checkout master
echo "third row of text on master branch" > a.txt
git commit -a
git merge 681d9911379f4bed16903c876b72243e3de7d4dd
git log --graph --pretty=oneline --abbrev-commit

The resulting git tree.

* 0ffb123 Merge commit '681d9911379f4bed16903c876b72243e3de7d4dd'
|\
| * 681d991 Text added on v1.0 branch
* | 5c8800b Third row of text on master branch
|/
* 0496fc8 Added a second row of text to a.txt
* f5251a8 Initial commit, adding file a.txt