Release branches for documentation

[akihikodaki]

Some changes of Mastodon such as #234 and #235 requires this documentation to be updated, but it is not necessary or possibly inappropriate for past releases. Could we have a branch for releases, as mastodon repository has 1.3-stable?

[dariusk]

This is a good idea. It'll require a lot more coordination between the docs team and the dev team, which is in my opinion what we want anyway.

The dev team has started using Github Projects to track tagged releases, so maybe that's a place to start. @wxcafe what do you think of this?

[wxcafe]

I think it'd be cool, but I'm not sure it's realistic to have valid, complete docs for a release the day it's released right now. It could be someday, but not for now.

We can still freeze the state of the docs at each release and tag that state the same as the release, tho, doesn't hurt.

[isoboroff]

Just to add a "me too", the recommendation on the website for running a server is to use a tagged release rather than the master branch, but then it's not clear how to get the corresponding documentation.

[wxcafe]

The current status on this is that we don't have nearly enough people taking care of the doc and/or a stable release mechanism to make it work. I guess the best way to achieve this would be to have a period where the doc is checked before each release, then imported into the main project. That way you'd have access to documentation related to a specific version, and it'd be easy to just browse that specific version (and you'd have it with your install if needed). That is not feasible given the current release rate afaict (and the current release rate is pretty cool, as it gets more features and improvements in and keeps engagement going, it just doesn't enable this.)

[wxcafe]

@Gargron let's maybe do something about this for 2.0 and later releases? ❤️