You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Essentially, I'd like to change all user-facing documentation links to point to latest rather then edge. I also propose changing the docs theme to make it more obvious what documentation version you're using.
I was confused about the absence of an unreleased feature from the latest release because I was reading the docs for edge rather than the latest release.
I remember seeing the message on the landing page that "This documentation is versioned". I didn't know that I'd pulled "latest" rather than "edge" from docker hub. By the time I'd encountered the version-related issue, I'd forgotten that I was on the edge documentation rather than latest.
Here's what I did:
I used the docs linked from project description, which took me to the docs for edge.
I started on the usage page. That page had me download docker-compose.yml and mailserver.env from master.
The path of least resistance had me working with master/edge rather than the latest release, which is maybe not ideal, but it was consistent so far.
I edited mailserver.env according to the comments in it (big fan of this workflow btw).
I ran docker-compose. The docker-compose.yml from master pulls latest, not edge. So now I was working with the image from latest, but with the docs and commented mailserver.env from edge.
Not wanting to bother with DKIM initially, I set ENABLE_OPENDKIM=0, an edge-only feature. It didn't work, so I opened [BUG] OpenDKIM running when disabled #3169 in error.
Describe the Solution you'd like
Change the user-facing links
I think we should replace every user-facing link to the edge docs with a link to the latest docs. Everyone who is getting started with docker-mailserver will start with the latest release. So this would mean certainly changing the project description, README, docker hub description, mailserver.env comments, and maybe more.
...But what about links in the docs? Right now the edge "Usage" page has people download mailserver.env and docker-compose.yml from master. How will each version after 12 tell people to download the right docker-compose.yml and the right mailserver.env? Does this problem show up anywhere else in the docs? Has it already been solved somehow? I don't know. Does anyone know?
Make the documentation version easier to identify
Change the mkdocs theme to display the version even after scrolling down. Now, if you're scrolled down, the only way to know what version you're looking at is the URL.
Are you going to implement it?
Yes, because I know the probability of someone else doing it is low and I can learn from it.
What are you going to contribute??
One thing I could do is make a latest version of the docs that points to the last release, so that the links in the description etc. wouldn't have to be changed every release, then change the links.
I could also look into modifying the theme to keep the version displayed after scrolling down. Perhaps with the first change this won't even be necessary though!
Additional context
Alternatives you've considered
I outlined two solutions that could both be implemented, but if one of them is unsatisfactory, I could just do one or the other.
Feature Request
Essentially, I'd like to change all user-facing documentation links to point to
latestrather thenedge. I also propose changing the docs theme to make it more obvious what documentation version you're using.Context
#3169
Is your Feature Request related to a Problem?
I was confused about the absence of an unreleased feature from the latest release because I was reading the docs for edge rather than the latest release.
I remember seeing the message on the landing page that "This documentation is versioned". I didn't know that I'd pulled "latest" rather than "edge" from docker hub. By the time I'd encountered the version-related issue, I'd forgotten that I was on the
edgedocumentation rather thanlatest.Here's what I did:
I used the docs linked from project description, which took me to the docs for edge.
I started on the usage page. That page had me download
docker-compose.ymlandmailserver.envfrommaster.I edited
mailserver.envaccording to the comments in it (big fan of this workflow btw).I ran
docker-compose. Thedocker-compose.ymlfrommasterpullslatest, notedge. So now I was working with the image fromlatest, but with the docs and commentedmailserver.envfromedge.Not wanting to bother with DKIM initially, I set
ENABLE_OPENDKIM=0, anedge-only feature. It didn't work, so I opened[BUG] OpenDKIM running when disabled #3169 in error.
Describe the Solution you'd like
Change the user-facing links
I think we should replace every user-facing link to the
edgedocs with a link to thelatestdocs. Everyone who is getting started with docker-mailserver will start with the latest release. So this would mean certainly changing the project description, README, docker hub description,mailserver.envcomments, and maybe more....But what about links in the docs? Right now the
edge"Usage" page has people downloadmailserver.envanddocker-compose.ymlfrom master. How will each version after 12 tell people to download the rightdocker-compose.ymland the rightmailserver.env? Does this problem show up anywhere else in the docs? Has it already been solved somehow? I don't know. Does anyone know?Make the documentation version easier to identify
Change the mkdocs theme to display the version even after scrolling down. Now, if you're scrolled down, the only way to know what version you're looking at is the URL.
Are you going to implement it?
Yes, because I know the probability of someone else doing it is low and I can learn from it.
What are you going to contribute??
One thing I could do is make a
latestversion of the docs that points to the last release, so that the links in the description etc. wouldn't have to be changed every release, then change the links.I could also look into modifying the theme to keep the version displayed after scrolling down. Perhaps with the first change this won't even be necessary though!
Additional context
Alternatives you've considered
I outlined two solutions that could both be implemented, but if one of them is unsatisfactory, I could just do one or the other.
Who will that Feature be useful to?
New users
What have you done already?
Nothing