New Wiki
Open, ConfirmedPublic

Description

NOTE: The new Wiki is in it's transitional phase atm.

It’s goal is much more limited than previous one, basically this is a
developer/module team members tool to share technical docs. It should
also have general help info like setting up a new build of blender, some
code architecture docs, etc.

Moving a subset of old wiki pages is on-going process.

Old wiki shall be locked (made read-only) in a few weeks, proposed date
is June 15th. That means that developpers (also including GSoC students)
should request accounts on new wiki if they do not have one already, and
move their pages there.

Note that once in read-only state, it will still be possible to access
and copy wiki-markup content of the pages!

Recently Dan set up a fresh install of Media Wiki and migrated the old pages to it. This can be found at https://en.blender.org

To set up an account (developers only) just informally poke a wiki administrator for now
[these are @Campbell Barton (campbellbarton), @Brecht Van Lommel (brecht), @Sybren A. Stüvel (sybren), @Dan McGrath (dmcgrath) atm]

There are still several todos

Theme

  • We should keep the theme as close to the original to make maintenance easy.

Clean Structure

  • Remove the wiki versions (2.4, 2.5, 2.6) and instead only have one that is alway the latest.
  • Make all pages independent. Pages like https://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Windows/msvc/CMake are really confusing to edit.
  • Remove namespaces, so [[Building_Blender/Windows]] instead of [[Dev:Doc/Building_Blender/Windows]] (can be done after creation by "moving" the page)

Excluded from Wiki Migration

There are a couple of sections that mostly contain historic content and it is preferred to not port these over
(but this has to be checked carefully -- if in doubt, ask around... help in these decissions is welcome!)

What still needs to be done

  • Building
  • Tools
  • Developer Introduction
  • port Architecture docs (this is higher priority but needs special care to make sure we dont port "out-of-date" information)
    • Bmesh
    • RNA / DNA
    • ...
  • port Addon catalogue / docs (these will be moved to the blender manual [https://docs.blender.org/manual] though -- some of the docs already made their way into the new wiki but have to be moved again [to manual]), also see T54097
  • move Todo section (https://wiki.blender.org/index.php/Dev:Source/Development/Todo) to phabricator (parent) tasks. This way intern-linking (existing) phabricator TODO tasks is just more useful, too. As a first step, this has now been brought over in its current stats, see T55361 (and subtasks). These will now have to be cleaned up to remove "out-of-date" content.
    • Tools
    • Render
    • User Interface
    • Animation System
    • Game Engine (exclude this)
    • Editors
    • Breaking Backward Compatibility
    • Scripting
    • Import Export
    • Building Software
    • Installation, Environment
    • Regression Tests
    • User Based Todo (exclude this)
  • port Release Logs over (this is lower priority but does not require checking if content is out of date). For older releases up until 2.78 it was decided to just link to the old/archived wiki for now (lots of broken links / missing content / not subject to further editing anyways...).
    • Blender 2.80 (under development) note: https://wiki.blender.org/index.php/Dev:2.8/ hasnt been ported (yet?)
    • [real port] Blender 2.79 (latest stable release)
    • Blender 2.78
    • Blender 2.77
    • Blender 2.76
    • Blender 2.75
    • Blender 2.74
    • Blender 2.73
    • Blender 2.72
    • Blender 2.71
    • Blender 2.70
    • Blender 2.69
    • Blender 2.68
    • Blender 2.67
    • Blender 2.66
    • Blender 2.65
    • Blender 2.64
    • Blender 2.63
    • Blender 2.62
    • Blender 2.61
    • Blender 2.60
    • Blender 2.59
    • Blender 2.58
    • Blender 2.57
    • Blender 2.56
    • Blender 2.55
    • Blender 2.54
    • Blender 2.53
    • Blender 2.52
    • Blender 2.51
    • Blender 2.50
    • Blender 2.49
    • Blender 2.48
    • Blender 2.47
    • Blender 2.46
    • Blender 2.45
    • Blender 2.44
    • Blender 2.43
    • Blender 2.42
    • Blender 2.41
    • Blender 2.40

Details

Type
Design

I don't know that I would go so far as to remove the old 2.4/2.5 manuals that exist in the wiki as they are the only manual that exists for them, unless people feel we could just assume it to be deprecated and removed from existence.

I wonder if it would be better to maybe try doing a one time conversion of the old 2.4 wiki manual back over to sphinx, once we do versioning over there with the manual. At least then we could provide redirects to the manual that would be indexed by Google and searchable/findable by people with old versions of Blender, or people who are merely curious.

As for how to structure and layout the updated wiki, I don't really have any opinion here as I am not the person that edits stuff. If you like using transclusion to create pages, that's up to the editors.

On the topic of a theme, Naiad is currently broken for the navigation tree on the left of the page. Personally I say scrap it; it looked nice but was too coupled (IMHO) to the extensions and templates/transcluded pages etc. I also believe it has problems with mobile? Anyway, I think it to be a terrible design when half the site breaks just be changing to a stock skin, like vector.

I also am curious what others think about the idea of moving to a Wiki family and using interwiki links for languages (eg: fr.blender.org, de.blender.org, pool.blender.org, etc.) for translation of everything else on the wiki, very much like how wikipedia does things.

Aaron Carlisle (Blendify) raised the priority of this task from Normal to Confirmed.

Ok, I think I have a clearer idea about the whole old wiki version things. We should keep the old manuals but not have wiki version for the rest of the wiki. Here is my idea on how this should be structured.

  • Home Page
    • Manual
      • Current (redirect)
      • 2.5
      • 2.4
    • Other wiki pages

I don't have a strong opinion on whether the old manuals get moved to sphinx.

Hello everyone !

Manual theme redesign
Current vogue is in the material and flat designs.
I think the wiki could benefit of efficient space usage just as shown in this image.

A little bit of CSS magic can help change the current wiki remake to be on the same level as:

Manual versions
As far as the old wiki goes; I think we should keep the latest major versions just for retrospective [2.40, 2.50, 2.60, 2.xx ].
There should also be a latest version, updated on the fly.

Thanks a bunch Dan for setting up new wiki! :)

Content

2.4 and 2.5 manuals: those would simply remain readonly, kind of 'archived'. I don’t see much point on wasting time on them to port to sphinx or whatever, but there is no reason to remove them either, they can be 'forgotten' in their own corner imho. :P

In fact, maybe we could have an 'archived' section in the wiki, where we explicitly dump any page which is no more in sync with current blender - would include said manuals, but also all old design and tech docs that are no more really relevant. This way, no need for 'version' name spaces.

Skin

Agree it would be nice to make it coherent with other blender sites, but imho most important thing is to have something easy to maintain and update along with wikimedia. So rather use a well known and maintained skin (even default one?), with a few as possible customization (css-only ;) ).

Naiad was a great result, but trying to make wiki not look like a wiki requires tremendous work - to create it and to keep it working at each update! Let's not forget that wiki, now that manual uses its own stuff, will mostly be tech doc place. We want to keep it simple and easy to use and maintain, more than everything else.

The problems with Naiad is (currently) the Nav tree is missing. The problem with Any of the stock skins is that we have a bunch of Naiad related cruft in the templates that make a stock nav area break, so things need clean up if we want to go that route. It doesn't matter to me either way; I am just letting you know that if we go with a stock setup, there is a lot of work needed to clean things up and bring it back to a stock setup.

+1 for @Bastien Montagne (mont29)'s reply.
Best we have wiki that can be maintained and not focus too much on customization unless if gives real practical benefits and doesn't prevent us from upgrading in the future.

Hi,

Skin:
I have no idea how much work is to setup the new skin, vs stripping down our current version to be compatible with the default skin.
That being said, I am all in favor for css tweaks so that it looks like the other blender websites, as long as it is not too much work.
I am not so worried about styling, but about the functionality of the navigation.

Content:
+1 for read-only versioning. I understand that this means to keep the content as it currently is, with new material going to sphinx.

I think the default skin is better than going back to the old Naiad.

I started to do some cleanup of the current wiki today, mostly in the release notes area, but ran into a problem when trying to delete pages.
Currently, there is no way to batch delete files. I did a simple Google search and found some solutions that might help:

However, there may be a chance that these will not work due to the old media wiki version that we use.
In this case, I think that we should layout a day where shut down the wiki and move to the new wiki.
From here we can use those scripts to delete many pages that we don't need. A big example
here would be the old manual translations (2.4, and 2.5, 2.6).

So this is mainly a question for @Dan McGrath (dmcgrath) on whether the scripts would work or not,
If not we need to get a time frame for when to shut down the wiki and make the new wiki default.

Hi @Aaron Carlisle (Blendify),

There is a problem with the current wiki in that we cannot add new extensions. Normally when you add an extension you need to run an upgrade script to extend the database schema, but this script is broken in the current database due to a problem with Latin/UTF problems, so we wouldn't be able to activate new extensions. The problem gets fixed when we upgrade Mediawiki though, so the new system would be able to run these extensions just fine, and I believe are even included in the new site.

It may be possible that I can I run some of the admin scripts in the shell to delete specific urls though. Looking at the shell, I do see a "deleteBatch.php" script. It appears to take a text file with a list of pages to delete:

  • <listfile> : File with titles to delete, separated by newlines

Maybe this would be enough? Or would you guys rather wait and switch to the new wiki instead?

It seems like you are talking about https://www.mediawiki.org/wiki/Extension:DeleteBatch which was the second bullet point.

No, there are php scripts in the maintenance folder in Mediawiki installs that let you do stuff that may or may not be available through the web UI. The extensions I think are more meant for people without shell access.

Eeeeeeekkkkk!

From here we can use those scripts to delete many pages that we don't need. A big example here would be the old manual translations (2.4, and 2.5, 2.6).

Where was this ever agreed on? Translations should be handled the same as english manual imho, archived and made non-editable, but why deleted?

After trying to work on T48381 I found that the current wiki is too slow for me to do anything.
I think the best solution right now is to do a little theme clean up and make the merge to en.wiki.blender.org
After everyone is forced to use en.wiki.b.o pages can be added/removed/moved has needed with a lot more ease.

I have just checked the manual, and there have been performance improvements, so it should be back to normal now.

Hi;
Today i found in the official wiki that vimeo videos seem to be embedded by using the flash video player. I propose to customize or update the <vimeo> plugin so that it uses the html5 player instead. Here is an example page:

https://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.78/Physics

When i open this page with firefox, then i get the warning about usage of flash.

I also noticed that it looks like the new wiki does not (yet?) support the <vimeo> tag. I believe it is important to at least support embedding of videos from vimeo and youtube.

Aaron Carlisle (Blendify) changed Type from Bug to Design.Feb 8 2017, 6:30 PM

Hello.

Is it planned to allow to log in to the (upcoming) new wiki with a developer.blender.org account?
I hope it will be considered because it's not currently possible to log into wiki.blender.org with a developer.blender.org account...

Thanks.

hi,
https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts
could be archived and a new set of pages created for addons.
as one of the original authors and designers of this page and
https://wiki.blender.org/index.php/Extensions:2.4/Py/Scripts
I would be happy to work with wiki devs to see the new pages created for blender 2.8 series.

I was about to update the new wiki, move/copy more stuff from the old wiki, I can log in using the credentials from the old wiki but I dont have editing permissions in the new wiki.
Could somebody set this up for me [or tell me how to do it myself]?
Thx in advance!

I was about to update the new wiki, move/copy more stuff from the old wiki, I can log in using the credentials from the old wiki but I dont have editing permissions in the new wiki.
Could somebody set this up for me [or tell me how to do it myself]?
Thx in advance!

The wiki was meant more for testing. There will be no porting over as the actual port work will involve disabling updates to the old site, and then doing a database dump into the new wiki, followed by shutting down the old one and renaming the new one.

I think after the 2.8 release should be a good time for this even if we use the default wiki skin.

port Addon catalogue / docs (these will be moved to the blender manual [https://docs.blender.org/manual] though -- some of the docs already made their way into the new wiki but have to be moved again [to manual])

I would like to handle this and I want to create a separate design/structure document before we go about that.

Help > Release Log link will have to be updated after the switch.

I just saw the big wiki changes happened today. Two questions:

  1. Is there more information available as to the reason for the migration to a new wiki? I looked over this thread, but I'm not seeing much in the way of specifics. This would be helpful in a FAQ point of view, in establishing some rough rules/guidelines, and for preventing any perceived negative aspects from the old wiki from creeping into the new one.
  1. Is there more information about what is being migrated over and what isn't? For instance, the old tutorials (e.g. Modeling Two dice)? Templates? User pages? Feature requests / design mockups? Docs on depreciated Blender features (e.g.: Blender Internal)? User add-on docs (for the add-ons not shipped with Blender)? Summer of Code pages for previous years? I'm guessing no for the tutorials and feature requests, but I was not as sure about the other items I listed.

https://wiki.blender.org/index.php/Dev:Doc/Process/Bug_Reports should be migrated, as it does serve some purpose for bug reports.

I find that at the moment the state of the move is a bit messy with a lot of broken links and no visible plan.

@Dan McGrath (dmcgrath) is it possible to rename the old wiki from https://en.blender.org/ to https://archive.wiki.blender.org/ ?
This would help make clear for any reader why is that wiki read-only.

Is there any plan with redirects?

Example of links that no longer work:
http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Linux/Generic_Distro/CMake (should be on the new wiki)
http://wiki.blender.org/index.php/Dev:Doc/Code_Style (should be on the new wiki)
http://wiki.blender.org/index.php/Dev:2.5/Source/Architecture/DataAPI (should be on the old wiki ?)
http://wiki.blender.org/index.php/User:Brita/Configs/VSCode (do I need to move my user space pages manually?)
http://wiki.blender.org/index.php/User:Dfelinto#Git (what about someone else's user space that may or may not still be active?)

I see that there is a redirect from http://wiki.blender.org/index.php to https://wiki.blender.org/wiki but then the page is still not there.
Is it possible, in that case, to redirect to https://archive.wiki.blender.org/ ?
Or for every single page to show at the top "This article was also found on the <archive>", with a link?

@Dan McGrath (dmcgrath) is it possible to rename the old wiki from https://en.blender.org/ to https://archive.wiki.blender.org/ ?
This would help make clear for any reader why is that wiki read-only.

The old wiki will be destroyed/deleted at some point (have yet to pick an actual date). There is a dump of the files already available now for others to import into their own private MediaWiki installations so that they can retrieve old articles to migrate them to the new wiki. Long story short: there shouldn't be any confusion because nothing should be referencing the old wiki.

Is there any plan with redirects?

Redirects that aren't external to the actual wiki (ie: https://wiki.blender.org/) should be handled in the wiki itself by creating a page at the "broken" location, and then redirecting it to the new location. External URL's would require another MediaWiki extension, so they can be done via the web server redirects.

Example of links that no longer work:
http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Linux/Generic_Distro/CMake (should be on the new wiki)
http://wiki.blender.org/index.php/Dev:Doc/Code_Style (should be on the new wiki)
http://wiki.blender.org/index.php/Dev:2.5/Source/Architecture/DataAPI (should be on the old wiki ?)
http://wiki.blender.org/index.php/User:Brita/Configs/VSCode (do I need to move my user space pages manually?)
http://wiki.blender.org/index.php/User:Dfelinto#Git (what about someone else's user space that may or may not still be active?)

As I alluded to above, where there is a missing page that needs to exist, it should be copied from the old wiki to the same exact spot in the new wiki, then moved and edited to match the new policy and style guidelines that were decided on. So your personal page(s) you would copy and migrate (or by all means try ask one of the wiki "guru" to possibly bulk migrate your stuff for you, perhaps?) to the new wiki.

I see that there is a redirect from http://wiki.blender.org/index.php to https://wiki.blender.org/wiki but then the page is still not there.
Is it possible, in that case, to redirect to https://archive.wiki.blender.org/ ?
Or for every single page to show at the top "This article was also found on the <archive>", with a link?

Again, the old wiki is a maintenance nightmare (and the whole point of us starting the wiki from scratch) and potential security risk (unmonitored/maintained php code silently being abused on a server). The "archive" is already available at https://download.blender.org/oldwiki/ in a format that any MediaWiki installation should be able to import. If someone feels like spending time to parse out all of the pages into separate wiki markup files, perhaps we could host that in this directory as well. Space isn't a concern, but someone needs to split the files up and provide me a tarball for us to host.

As for the exact cut off date, I'm flexible here, but at some point we really do need to take it offline. Making things read-only doesn't actually protect us. Anyway, I hope this answers a few questions?

Hi @Dan McGrath (dmcgrath), thank you for the explanations, that made the current situation a lot clearer to me!
I was under the impression that making the old wiki read-only would also protect it from spam & etc, but I see that if it's still old unmaintained php code running on the servers, that's not very good :)

I tried downloading the archive, (which is great to have and reasonably small, so that's great!), but I am not sure what to do with it.
Meaning: I don't think it is reasonable to expect regular people going through all the pain of downloading the archive, unzipping and searching through it after finding a broken link on the web.

I can go through my own user space and manually put it on the new wiki, no problem.
But what's the plan for other people's spaces, old design documents, addons, old manual versions and links that just don't match anymore (like the CMake one above)?
Is it to batch process all of these these pages into the new wiki? Can the new mediawiki installation just import the entire thing?
You mentioned someone should do this, page by page and manually?
Would it be better to try and process original design docs and manual versions into really-read-only-non-php versions?
Or is there some user friendly "viewer" for this xml archive?

Last important question! Who are these wiki "gurus"? :)

(Sorry for all the questions, maybe I missed out on reading something?)

Hi @Dan McGrath (dmcgrath), thank you for the explanations, that made the current situation a lot clearer to me!

No problem!

I was under the impression that making the old wiki read-only would also protect it from spam & etc, but I see that if it's still old unmaintained php code running on the servers, that's not very good :)

Well, having it locked down and read-only prevents modifications and most annoyances, but it's the risk of just leaving an already old and vulnerable app running that concerns me.

Sure we could, in theory, upgrade the old wiki, but it would break the pages horribly, and then I would be stuck maintaining two wikis! Worse, the old one is a horrible mix of multiple svn repos. Originally they had it setup to have an internal (secrets!) and an external (public) svn repo, and would cherry pick commits from one to the other. It was already a headache to maintain, then commits stopped and we have a mess of partially committed changes. I'd rather eat spaghetti, not maintain it :D

I tried downloading the archive, (which is great to have and reasonably small, so that's great!), but I am not sure what to do with it.
Meaning: I don't think it is reasonable to expect regular people going through all the pain of downloading the archive, unzipping and searching through it after finding a broken link on the web.

Yeah, the files are fine, but the massive xml dump is really something that would need to be processed by py/perl/sed/awk type scripts, or by just importing it into a vanilla wiki. Either way, it's a ton of work! This is why I was really hoping that people would take the migration a little more seriously, because I honestly have a million more important things to do than also migrate the wiki :(

I can go through my own user space and manually put it on the new wiki, no problem.
But what's the plan for other people's spaces, old design documents, addons, old manual versions and links that just don't match anymore (like the CMake one above)?

All very good questions! The understanding that I have is: if it's an important page, migrate it; if it's not migrated, then it will (eventually) go to the bit bucket in the sky and all traces of it's existence be forgotten! The exception of course being this "secondary" archive of the page dump.

Is it to batch process all of these these pages into the new wiki? Can the new mediawiki installation just import the entire thing?
You mentioned someone should do this, page by page and manually?

As for batch processing, yes the process that dumped the pages can also import the pages. Problem is that because they tied all of the page markup into theme code, you can't even get a page to display without our theme, iirc. Still, if you can get the original markup text, you should at least be able to manually salvage a decent amount of content out of what you can get.

Realistically, you would probably want to apt-get install a mediawiki in a VM or something local, import the old pages, and then create a modified manifest of everything you want to keep, then export those pages only for import into the new wiki. Be warned though that the old pages are horribly tied to the old theme and templates! It would be a frustrating experience to bulk migrate it short of copying all the old junk that we decided to remove in the new wiki, and we would be right back to square one: an unmaintainable wiki

Would it be better to try and process original design docs and manual versions into really-read-only-non-php versions?

I assume you mean a wget or something that is "static" html. This process can work, but then all the old urls and pages get horrible urls. Worse, the search engines will start double indexing stuff, unless you exclude it with robots.txt etc etc. It's all just a headache, tbh. Take a look at archive.blender.org. Then look at the page source!

Or is there some user friendly "viewer" for this xml archive?

In all honesty, it's meant to be dumped from mediawiki to xml files, then imported back into mediawiki. But sure, if you have the xml-fu skills, one could slice and dice it all up into something useful. All comes down to how much time one wants to spend sifting through the sand to find the gold nuggets! ;)

Last important question! Who are these wiki "gurus"? :)

Good question :) @Ivan Paulos Tomé (greylica) and @Bastien Montagne (mont29) were the best (only?) guru's I think we had. I barely know anything about MW myself, which is why I try to stay out of this other than from an admin with the actual access POV. Perhaps someone from #mediawiki or #wikipedia would have sympathy and help out a bit, but we don't have an open system because of the headaches of drive-by spam and lack of moderators. Perhaps we should put out a call for an actual MediaWiki administrator?

(Sorry for all the questions, maybe I missed out on reading something?)

No worries! Nice to discuss things for others to get caught up on the situation and some of the difficulties of it all.

Plan for completing the wiki migration:

Old wiki archive
As I understand it, even though the current 'old' wiki is read only, it is still an installation of old php code that is a security hazard.
Can we please make the final html read-only version and put it on the final domain "https://archive.wiki.blender.org/"?

This would allow for pages to explicitly link to the original version of a page or to pages that were not ported.


Broken links
Links that people referenced somewhere or bookmarked should never be broken.
If there is no page for it on the new wiki, I propose that the 404 error page on the new wiki presents a link to the same page on the archived wiki (that may or may not exist).
Something along the lines of:
"The page you are looking for was not found.

  • Create it [link]
  • Search the archive [link]"

Purpose and scope of the new wiki
The new wiki is meant for developers and Blender contributors to talk about Blender technical topics.
It should, therefore, have:

  • Onboarding: how do you get started with compiling, understanding the code, translating, etc. (Dev:Doc)
  • Technical Documentation: design docs, architectural decisions, etc (Dev:Source)
  • Projects: Onboarding and coordination over a project such as GSoC or any other (Dev:Ref/GSoC)
  • User space: a place for weekly reports, WIP proposals, drafts and personal ramblings in general. (User:)

In my view, this leaves out:

  • Feature Requests (Dev:Ref/Requests) - These were already dropped in favour of Phabricator.
  • 'Deprecated documents' such as old proposals, meeting notes, etc. - These are already unused (although they should still be accessible with a direct link).
  • User Manual - Already dropped in favour of https://docs.blender.org/manual
  • Python Add-ons

The future of these is under discussion on T54097. For now, existing links should work.

  • Release Notes

I propose that release notes for the different Blender versions are kept only in https://www.blender.org/download/releases/
The new wiki can still hold the notes for the version current under works, which allows for collaboration on making the release notes and that's all.

At the moment, the release notes pages were already copied to the new wiki, but there are many problems, such as missing images, templates, broken links, broken structure and bad formatting.
I tried to fix it for a bit, but it's really inglorious work to even check if version 2.49 of Blender looks ok. I think this should be left as it was and the copied pages should be removed.


My proposed points of action:

Here are some instructions which might help with static-isfying the old wiki: http://camwebb.info/blog/2012-12-20/

This all seems reasonable.

Regarding release notes, it's not entirely clear to me what is being proposed. Once the old wiki is archived to HTML we can redirect to that for old versions, and then afterwards remove the old versions from wiki.blender.org. I'm not sure if anyone will convert the wiki release notes of the current or future releases to blender.org though, that's a lot of work. If we want to have the release notes in another format for future release we better write it in that format directly, otherwise we probably just keep linking to the wiki.

One request regarding the new wiki I would like to see: explicit version numbers. The new wiki does not specify which version of Blender the articles are relevant to. Something I appreciate that the Python documentation does and the old wiki does is have a selectable version dropdown menu which allows you to make sure the version of the page you are reading is correct for the version you are working with, and select a different version and be immediately taken to the correct page. I've been hitting a lot of dead links lately trying to figure out which set of build instructions is correct for 2.7, which has been a bit difficult since the old wiki does not have anything labeled 2.7, but the instructions in the new wiki are specific to the latest builds of 2.8.

EDIT: I see that one of the goals of the changes is to remove version numbers and always have it up to date to the latest versions. I suppose I simply disagree with this for the above reasons.

@Benjamin Humpherys (brhumphe) The Blender User Manual does have versioning: https://docs.blender.org/manual/ . But you say compile? That shouldn't really change, it would be nice to have an easier explanation of how to work with branches, but otherwise, I don't think it needs versioning.

@Brecht Van Lommel (brecht)
Regarding release notes, I propose to delete everything under https://wiki.blender.org/wiki/Reference/Release_Notes except for the ones for 2.80.
This is because the copies don't look good and it would be too much work to make it better, without a clear benefit.
Examples:
https://wiki.blender.org/wiki/Reference/Release_Notes/2.49
Compare an original version with the copy. -> Images are missing. Click the first link "Cycles Rendering". Images are also missing and links are broken.

I thought that the wiki release notes were already converted to blender.org by @Pablo Vazquez (pablovazquez) or @Francesco Siddi (fsiddi) ?

@Benjamin Humpherys (brhumphe), the versioning in the old wiki was never actually used for developer docs. The individual history of pages can be used to go back to a specific date, however build instructions are actually identical for master (2.7) and blender2.8 branches.

@Inês Almeida (brita_), wiki release notes don't get converted, there is only a landing page on blender.org that links to the wiki pages. We can delete the release notes on wiki.blender.org once there is a way to redirect to the archive versions of those pages with images, if we delete them right now it breaks a lot of links.