Start using a Changelog

[eleazar]

On some of the other open projects i've worked on a changelog text file was updated when significant changes were made by any committer. I realize that it is not nearly so vital in a project like ours with a small number of participants, but i think there would be minor advantages.

1) It's a little easier to make the list of changes for the release notes when the time comes.
2) Those who download the source and/or data from SVN get a more up-to-date assessment of what's been changed than looking at release notes, and a more concise list than the SVN log provides.
3) It's more convenient than checking Sourceforge's commit log -- which usually takes forever to load for me.

So, if there's no objection(s) i'll get it started. I've got the previous changelog entries in a document.

EDIT: for instance, i would write something like this for the work i've done since v.3.16. (I strongly recommend headings dividing it into logical categories, if not necessarily these exact headings.)

v0.3.16 + SVN

Graphics:
• Added binary star variant star graphics
• Added new building graphics

Ballancing:
• Decreased cost of colony pods by 25%

Species:
• Added a lot of minor "native" species, a few of which have extended descriptions.

[Geoff the Medio]

If you want to maintain such a file, that's fine, but I'm not keen on having to add another step to doing commits...

I'm not sure how things work with the SVN on OSX, but in TortoiseSVN on Windows, you can show the commit logs from specified ranges, defaulting to the 100 commits, and this loads fairly quickly.

Command-line SVN also has the "svn log" command. I've never used it, but I suspect it would display the commit logs quicker than the web interface. Probably this can be piped to a log file for later review. I think it can also be told to display a specific range of log messages, including up to the most recent.

Categorizing changes is probably a good idea for the release notes as well.

[eleazar]

If you want to maintain such a file, that's fine, but I'm not keen on having to add another step to doing commits...

It wouldn't necessarily be a step for every commit. Many of your recent commits would be nicely summarized by one entry, "~ Partial implementation of ground invasions." But whatever, i wouldn't want record-keeping to get in the way of actual work for you.

I'm not sure how things work with the SVN on OSX, but in TortoiseSVN on Windows, you can show the commit logs from specified ranges, defaulting to the 100 commits, and this loads fairly quickly.

Command-line SVN also has the "svn log" command. I've never used it, but I suspect it would display the commit logs quicker than the web interface. Probably this can be piped to a log file for later review. I think it can also be told to display a specific range of log messages, including up to the most recent.

SVN log is good to know about. I'm still on command line, because last time i checked the free SVN GUIs for OsX were more of a pain to use than the terminal. But it's been a while, perhaps it's time to look again.

[Darkside]

On some of the other open projects i've worked on a changelog text file was updated when significant changes were made by any committer.

Is that posible for the eng_stingtable.txt too?

Or can them make a version number in the filname, after add some new parameters in the stringtable.
Becorse then its easy to controle the changes in there and translate them.
And update the file in the wiki page too?

[Geoff the Medio]

Is that posible for the eng_stingtable.txt too?

The changelog is about large additions and bug fixes, not a list of all changes to any particular file. If you want a list of all changes to the eng_stringtable.txt, you can look at the sourceforge revision history, here: http://freeorion.svn.sourceforge.net/vi ... t?view=log You can mark revisions and look at the differences between them, including the changes in each commit that modifies that file.