Rolling release

[TonyWhite]

Policy for rolling releases

The goal

Worry-free updates, even in the event of updates that break compatibility.

Simply run power-log --update command, and incompatible configurations will be handled automatically.

The policy

1. The work in progress is in dev branch.

2. The status of the dev branch reaches the goal.

   1. The script must contain the name of the release. For example: best.

3. Merge the dev into the main branch.

4. Create a new release

   1. Choose a tag (unique for each release). For example: best.
   2. Copy-paste the readme into description
   3. Add the script as attachment
   4. Edit the wget and curl links with the script release link

5. Edit the previous release (For example: current)

   1. Create the file next that contains the name of the new release. For example: best

What power-log --update does

Download the file next from the current branch

If next is not empty, it is the name of the new release!

If next is empty or 404 or other thigs, nothing happens.

1. The script download the new release
2. The old release will call the new one with the --install parameter
3. The new version will resolve any issues and proceed with the installation.

Obvious question

Q: Why not directly the name of the last version?

R: Beecause, if there is a broken update, the "bridge" release can keep user data consistent. Inconsistent data could:

• invalidate some rows of the log
• look for files in different folders
• and other things that could be changed in the future.

Thanks to this policy, the user is not forced to check whether the update broke anything. Or if some files need to be deleted.

[TonyWhite]

Thinking about it:

The old release will call the new one with the --fix parameter

This situation need these:

1. OLD checks for a new release
2. OLD downloads the new release
3. OLD calls NEW with --fix
4. OLD Proceed with update

Is it possible to streamline the procedure like this?

1. OLD checks for a new release
2. OLD downloads the new release
3. OLD calls NEW with --install

Q: Could this code be easier to maintain?

R: I think yes, because the installation is part of the update. The fix can be executed without a dedicated parameter. The fix is effectively a piece of installation.

Q: Does resilience increase, decrease or not change?

R: I think increase, because I avoid writing duplicate code. What if I publish a release with an update problem? I must public another release that fix the update problem. This sound like a "MicroMorbido" problem.