Skip to content
Johannes Meixner edited this page Feb 17, 2023 · 9 revisions

This page is currently under construction!

Draft

Why

The Relax-and-Recover bash code is written as a common effort by several main developers and many individual contributors where each one has his own personal background, preferences, and assumptions how Relax-and-Recover is meant to work.

We want to make it easier for everybody to understand the basic ideas behind how Relax-and-Recover is meant to work and subsequently to contribute code that works in compliance with those ideas.

In contrast to our Coding Style guidelines that mainly describe what the preferred technical form should be when writing Relax-and-Recover code, this Developers Guide is primarily meant to describe what the preferred behaviour is that the code should implement to achieve a consistent user experience.

Don't be afraid to contribute to Relax-and-Recover even if your contribution is not yet in full compliance with the way how Relax-and-Recover is meant to work. This is an ongoing step by step process.

The text below is currently (as of this writing dated July 2016) only meant as a preliminary proposal subject to further discussion:

The user's ultimate expectation: "rear recover" works

On the one hand the user would expect that after "rear mkbackup" had succeeded "rear recover" will also succeed.

The developer's impossible task: "rear recover" works

On the other hand it is in practice impossible to ensure that after "rear mkbackup" had succeeded "rear recover" will also succeed.

Goal: Reasonable compromise between ultimate expectation and feasibility

The way out of the contradiction between the user's ultimate expectation and what the developer can provide in practice with reasonable effort within finite (limited) time is a compromise between ultimate expectation and feasibility.

Specific guidelines about that compromise are subject to further discussion...

GitHub branches of rear

We have currently some branches:

  • master
  • rear-2.7
  • rear-2.6
  • ...

All commits will be done against the master branch and only when we are satisfied with the results then we will make a release branch. For details see our development page.