Good for a new contributor: Update ChangeLog

[NuclearMonster]

Our ChangeLog is very out of date, it hasn't been updated properly since 2008! This would be a large job that could be handled by someone who is willing to trawl through our commit history and cherry pick and update the ChangeLog with notable changes.

I can do this if nobody else does, but it'd be a good task for a new contributor who is willing to take it on so it would prefer for old timers like me to take a step back and let someone new handle it.

This task requires no significant coding experience or knowledge, simply a basic understanding of compiling software and the process of changing it over time.

It would probably be very tempting to do this with the assistance of an AI slop machine, but I believe that it'll be a lot better off if it's handled by a human who fully understands the context of the project or will learn that by working on this issue. So, please, do not use AI slop machines to work on it.

[Calinou]

Since ioquake3 is on a rolling release basis, what should be the cutoff for "versions" in the changelog? Maybe once per year? (A big continuous changelog spanning 17 years might not be very readable.)

[NuclearMonster]

Since ioquake3 is on a rolling release basis, what should be the cutoff for "versions" in the changelog? Maybe once per year? (A big continuous changelog spanning 17 years might not be very readable.)

so our last official released version was back in (yikes) 2009, we haven't really had a proper even rolling release due to our inability to ship per-platform installers.
Ideally we'd have an update to include whatever was in the 2009 release and then an Unreleased with everything since, but it's a good question if that is a good idea or not.

[smallmodel]

https://keepachangelog.com/ would effectively be great. A changelog must only include changes notable to players. The current changelog has tons of technical code details that could be removed.

About the rolling release, PRODUCT_VERSION gives hints, but it hasn't been changed since 2011. Perhaps there is an history of released builds over years? If not then put 1 version per year in the changelog?
Maybe stop at 1.36, and then use a commit hash as the version in the changelog?

[llbraughler]

I would say not only players but server admins and mod developers as well, there are many people people in the q3 community that depend on the source port. Perhaps it would be useful to have a separate README for those major subsystems and the new features/new cvars relevant to each type of user.

[NuclearMonster]

I would say not only players but server admins and mod developers as well, there are many people people in the q3 community that depend on the source port. Perhaps it would be useful to have a separate README for those major subsystems and the new features/new cvars relevant to each type of user.

We handle documentation for players and server admins with the website:

https://ioquake3.org/help/players-guide/

https://ioquake3.org/help/sys-admin-guide/

[NuclearMonster]

I should say, since I wrote that reply hastily, we still need to improve our documentation situation. This is perhaps an improvement from every part of the website being in this source repository, but it could be in another source repository if we could hook that up.

[NuclearMonster]

okay, nobody else has picked this up, so I'll probably take this up

[llbraughler]

What about an ioq3 wiki? Could make it easier to keep documentation up to date?

[NuclearMonster]

What about an ioq3 wiki? Could make it easier to keep documentation up to date?

We have had a wiki in the past, it is very time consuming and expensive in terms of resources to administer an externally-accessible wiki using at least the mediawiki software which was constantly bombarded by spambots that became more advanced over time while the anti-spam tools stayed largely the same.

The discourse forum at discourse.ioquake.org can perform similar functions, has basic wiki functionality, and is easier to maintain.