New branching model

[hirschmann]

With the latest beta release, I have updated the branching model.

Up until now, there was only one public branch (master) which acted as the "stable most of the time" branch. This branching model was pretty shitty because users and package maintainers couldn't be sure theat the master branch is stable and I couldn't publish new stuff as fast as I wanted.

Therefore I've introduced two new public branches, so from now on there will be 3 different branches:

• stable: for stable releases only (obviously)
• beta: for beta releases and preparing stable releases
• master: the public integration branch (default branch for pull requests). think of it as an alpha branch

If you have suggestions for improvements, please let me know 😄

[hirschmann]

@erkexzcx This might interest you

[erkexzcx]

@erkexzcx This might interest you

Heh, sure it is! I will push some updates to Arch Linux AUR.

The only question is - How about config profiles? I have few ideas:

A) Only 3 complete packages - Stable, Beta and Development.
B) 4 packages - Stable, Beta, Development packages without config profiles and separate package named "nbfc-configs" marked as a dependency for all 3 mentioned packages. Configs will be taken from Development version, since we want them as up to date as possible.

Thoughts?

[hirschmann]

Pushing not very well tested configs out to users of stable (or semi-stable) versions will cause havoc sooner or later.
There might also be configs on the master branch which rely on features which haven't been pushed to beta/stable yet.

I would opt for option A and a faster release cycle.

[erkexzcx]

Sure just give me few days to get those packages into AUR.

I just wanted to know if there are any new features planned/implemented? What is the purpose of making these new branches?

[hirschmann]

Take as much time as you need. Thanks for packaging NBFC for the AUR :)

I have planned several changes which are potentially breaking:

• switch from OpenHardwareMonitorLib to LibreHardwareMonitorLib for the Windows plugins (see Switching to LibreHardwareMonitor for more support ? #536)
• implement a REST API for the service (see [Feature Request] Gnome Extension for NBFC #531). I'm also thinking about dropping the WCF endpoint.
• improve the plugin and config system

All this stuff is much easier to implement when I'm able to push it to the master branch and get feedback early in the development process without having to keep the master branch stable.

[erkexzcx]

Thanks for explaining me this!

FYI - I just recently pushed some updates to nbfc and nbfc-git packages to AUR. Unfortunately, I consulted Arch Linux Forums in regards of having multiple versions of NBFC app in AUR and final decision was 2 versions - stable & development (because there is no need to have more nbfc packages in AUR, right?). So basically this is what I am going to continue supporting:

• nbfc - Your releases on GitHub.
• nbfc-git - Default (development) branch.

[github-actions]

This issue is stale because it has been open more than 180 days with no activity. If nobody comments within 7 days, this issue will be closed