Skip to content

Developer's Guide

Tonic Artos edited this page Mar 3, 2015 · 4 revisions

Branching

SuperSLiM follows the branch on feature git development process. You may know it as GitHub Flow. This process significantly eases the maintenance burden and pull process for all involved.

My particular approach

There are always slight differences so here is how I've been doing it.

All work, be it a fix, hot-fix, or feature, is performed on its own branch.

Master

Master tracks the latest development for the next major version. After a release is branched, a single commit is made to bump the version code and the snapshot version. From there no changes are made directly to the master branch. New features are branched off master.

Release branches

Releases are branched under the name early_release_#, or release_#. No changes are performed directly on the release branch. Updates are prepared in a temporary prepare branch off of the release branch. Changes in the prepare branch are, a commit of a single minor version number and version code bump, and a merge from the maintenance branch.

Maintenance branches.

Maintenance and release branches are branched at the same time. Naming is maintenance_#. This branch tracks all planned changes to the related release.

Fixes

Fixes are generally made off maintenance branches (hot-fixes), unless they are specific to the master branch. To apply a fix it is merged to the maintenance branche. It is also merged to the master branch if it is applicable. At some later date the maintenance branch, containing this and other fixes, will be pulled into a prepare branch, to be merged into the release branch.

If multiple versions are being supported, the fix is merged to any later maintenance branches, assuming the bug is present for the later versions.

Features

Features are branched only from master. They are merged only to master.

Caveats

The branch graph can sometimes be a little ugly.

Pull Requests

Submissions must compile when merged against HEAD on master.

If the changes do not conform to the project coding style (same as Android) then you'll be asked to fix it. It is easy to download one of the Android IDE codestyle configurations, and Android Studio should pick it up from the SuperSLiM project configuration automatically.

Getting Started

Read the documention and write a simple SectionLayoutManager. Once you've done that you should have a pretty good idea of how the LayoutManager and SectionLayoutManagers interact. From there you can get in to looking at how the LayoutManager is implemented and tackle some bugs.

Versioned Pages

0.4

[Getting Started](Getting started with version 0.4)
[User's Guide](User's guide for version 0.4)

version5 (WIP)

User documentation
[Basic usage](A simple tutorial)
[Advanced usage](All the cool things)
[SuperSLiM and RxJava](Using SuperSLiM with RxJava)

Developers documentation
Glossary
[The section graph](The section graph)
[Tracking data changes](Tracking data changes)
[Configuration transformations](Configuration transformations)
[Layout helpers](Layout helpers)
[Section configuration](Section configuration)
[Section state](Section state)
[Section layout managers](Section layout managers)
[Header layout managers](Header layout managers)

Clone this wiki locally