It would be nice if the new features and changes are documented on the Wiki.
The problem that might come up is what version number we should use to describe when the changes were made.

Given that we've had a alpha release for 1.12, it might be worth revisiting this. I realise that we didn't document anything for 1.80pr0 but that was substantially less stable and the change log was inconsequential.

I haven't kept up with this because of how rapidly things had been changing.. how much needs to be documented at this time?

It might be worth going through the merged pull requests and looking.

@dan200 can we have a label or two to help with this?

Off the top of my head, these changes are probably worth documenting:

• New methods to http API and handles. I've started documenting some stuff, but it needs work.
• Changes to binary mode in file handles.
• Speakers. I've put some stuff on the GH wiki but again needs some work.
• Terminal palettes
• Pocket API
• require and package maybe?
• A tonne of new settings.

We could use the GitHub wiki. The current wiki that we already have could track released versions of CC and the GitHub one can track the master branch.

Only concern with that is we would have a lot of duplicated information and the Github wiki is quite limited comparatively to copy directly over. If we just track change from the last release (new peripherals and methods, etc) that could be an option though.

I think my one worry there is you'll end up duplicating effort - whilst you can use MediaWiki on GitHub's wiki, it won't have any of the main wiki's templates - meaning that transferring content between the two is non-trivial.

Ideally we could create a series of drafts for the appropriate pages, then swap over to them when there is a release. Sadly I don't think drafts can be shared between users, which makes this less than ideal.

Alternatively, we can do what the Minecraft Wiki does and have an upcoming template to mark features on Github, but not yet in a release.

I don't think the wiki should be updated until there is a formal release. Whilst a couple of people are using custom 1.9/1.10/1.11 builds, the vast majority of people are still using 1.79 or 1.80pr0. Until then, it could get rather confusing.

Fair enough.

I know I'm necro-ing an old issue, but I wanted to say I think @KnightMiner's idea

If we just track change from the last release (new peripherals and methods, etc) that could be an option though.

seems the best option to me. Easy to access for looking at changes, and easy to pull from and delete when a stable release is published. Unless CC is going to fragment versions because of people building their own..

Unless CC is going to fragment versions because of people building their own.

If you make your own version then it should be up to you to provide your own wiki

Don't worry about the necro-ing, GitHub works differently to the forums. If the issue is not closed then constructive posts are welcome, if the issue is closed then look at why before posting (you may still be able to be constructive).