Refactor documentation + improvements

[alexis-opolka]

Is your feature request related to a problem? Please describe.
The current documentation of Navi is not always up to date and is not well structured.

It might be the occasion to introduce two things:

• A Quickstart/Getting started guide for new users (important!)
• A static website (via github pages, for example) for the documentation

Describe the solution you'd like
Refactor the current documentation into a well structured docs folder and update its content.

Describe alternatives you've considered
Do not update the documentation and do not improve anything.

Additional context
As how issues are growing unresolved and features are added without being documented, it seems to me that we are not walking on the right path here.
I would like for navi to be more documented and accessible to new users.

Side note to myself:

• https://github.com/denisidoro/navi/blob/138b7e0b0086f6c2d3cfd8274d7e616c5e980ab8/src/config/cli.rs

[welcome]

Thanks for opening your first issue here! In case you're facing a bug, please update navi to the latest version first. Maybe the bug is already solved! :)

[alexis-opolka]

@denisidoro I would like to have your thoughts on this.

[denisidoro]

Sounds good. I'll gladly review related PRs if someone has the cycles to send them.

[alexis-opolka]

@denisidoro I should have finished the new documentation by this weekend.
I'll surely send a PR this sunday.

[alexis-opolka]

@denisidoro Just a quick question but how are defined Navi versions?
What is considered a major change? A minor change? A fix?
Do you have a limit of minor versions before a major version?

It would be great if you could explain it to me so I can include it in the documentation, thanks. 😄

[denisidoro]

I don't think this is in set in stone but I'll share some examples.

What is considered a major change?

Anything which introduces a major breaking change. The bash to rust rewrite was such an example. If I had to stop supporting current configs then it would also be a major change.

Minor change

Almost everything.

A fix

In general any release that I need to do right after another. If I released x.y.0 but one day after I realized there was a typo in the help message and don't want to introduce any other features, I'd release x.y.1

[alexis-opolka]

@denisidoro @kit494way It would be nice that we don't accept any more PRs regarding documentation after #961 until I've finished working on its refactoring since the structure and the content has changed quite a bit and it's going to be more and more difficult to merge the two types of structures.

It shouldn't take me long to finish, approximately two weeks at my current rate.