ComputerCraft icon indicating copy to clipboard operation
ComputerCraft copied to clipboard

Update Wiki to reflect the new changes

Open CrazedProgrammer opened this issue 8 years ago • 12 comments

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.

CrazedProgrammer avatar May 21 '17 12:05 CrazedProgrammer

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.

SquidDev avatar May 21 '17 13:05 SquidDev

Fair enough.

CrazedProgrammer avatar May 21 '17 13:05 CrazedProgrammer

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.

Lupus590 avatar May 21 '17 17:05 Lupus590

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.

KnightMiner avatar May 21 '17 18:05 KnightMiner

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.

SquidDev avatar May 21 '17 18:05 SquidDev

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.

KnightMiner avatar May 21 '17 18:05 KnightMiner

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..

TangentFoxy avatar Sep 06 '17 23:09 TangentFoxy

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).

Lupus590 avatar Sep 07 '17 07:09 Lupus590

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.

SquidDev avatar Nov 14 '17 12:11 SquidDev

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

TangentFoxy avatar Dec 21 '17 03:12 TangentFoxy

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

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

Lupus590 avatar Dec 21 '17 10:12 Lupus590

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.

SquidDev avatar Dec 21 '17 10:12 SquidDev