Update politics

[MalteKiefer]

Maybe we should create a new Update politic so that the users get the latest updates faster.
Something like that:

Release Code: x.y.z
x -> Major release, something like a new category
y -> Minor release, new software added
z -> Fix release, only to fix typos, repos, folders, icons stuff like that

So when the copr is correctly configured it should build all by themself.
What do you think about that?
@kwizart

[kwizart]

I think we might only maintain one "major" version at a time anyway, so.
In my mind:
x -> Major is how the fedy software is built and main installation process (5.x means the version installable from copr).
y -> Second Major, is how the fedy code is updated (in javascript).
z -> Minor is about any content that is updated or component removed (after been deprecated).

But by update policy I would more means to have a guideline about which software can be added to Fedy and the order of preference.

• Main goal is to provide end-users facility to ease post-installation of popular software.

• Only provide one version of a component.

• Prefer software in fedora/rpmfusion that do not already have appdata file to be discovered automatically with the "Software" applications (or related apps).
  Ex: teams, onedrive, etc

• Add software from 3rd party repositories well known editors (google-chrome, lpf-spotify, microsoft-vscode)
  If FLOSS software are packaged by their editor but are not available in fedora/rpmfusion proper, only consider the editor version until a fully floss package is available in fedora/rpmfusion...

[kwizart]

And another important criterion 3rd party software installation must not break fedora/rpmfusion packages functionality. (mainly by not replacing fedora/rpmfusion packages/libraries).

[MalteKiefer]

OK i Like this way. maybe we should create then a Code of conduct

[leigh123linux]

OK i Like this way. maybe we should create then a Code of conduct

Maybe call it 'code guidelines' instead as I really hate the the term 'Code of conduct'

[MalteKiefer]

OK. Did you Check the maintainer settings Am 5. Januar 2020 11:37:12 MEZ schrieb Leigh Scott <[email protected]>:

…

> OK i Like this way. maybe we should create then a Code of conduct Maybe call it 'code guidelines' instead as I really hate the the term 'Code of conduct' -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #28 (comment)

-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[kwizart]

We can have both a "code of conduct" to protect contributors and maintainers in the case of conflict.
And a "Contribution guide" to state the general goal of the project and and the general policy about accepting new "plugins".

[kwizart]

@MalteKiefer I wonder if you can push a new version ? You were good at creating the changelog and the tag with thoses informations, I don't know how to do that yet...

[MalteKiefer]

I will take it. Give me some hours

…

On January 17, 2020 4:50:46 PM GMT+01:00, "Nicolas Chauvet (kwizart)" ***@***.***> wrote: @MalteKiefer I wonder if you can push a new version ? You was good at creating the changelog and the tag with thoses informations, I don't know how to do that yet...

[kwizart]

@MalteKiefer gentle reminder (about tagging).
I can do it, but it won't create a changelog as you did...

[MalteKiefer]

Sorry.
I make it now.

[MalteKiefer]

@kwizart done

[kwizart]

Seems like you forgot to bump the spec file, so the RPM took the previous version field, not the new 5.0.5.

[MalteKiefer]

thanks for fixing.