Standardize the changelog/issues format

[Utumno]

We should agree on the changelog and issues display format and automate their creation for the various text formats we use

• Nexus, First post, second post (issues open/closed) - bbcode
• Version history - html
• master changelog - markdown
• release changelog - markdown

Discussion in the form of patches to scripts/html.py and scripts/generate_changelog.py

For a variety of formats see the first posts on the forums - in all:

[Bug enhancement ?][issue number ?][Game ?] Title [assignee]

[lojack5]

@Utumno : I'm having issues with the new scripts trying to do a dry run for 305. I've used both master and rel-305.

1. This one's easy to get around: The CLI parser assumes you have Notepad++ installed, and that it's at Program Files. Mine's at Program Files (x86), but others may not have it installed at all. That's not a huge issue once you figure it out, but running the scripts without knowing that spits out an error message when it tries to call the editor, rather than checked to see if it exists before hand. I can clean this up if that's fine with you.
2. generate_version_history.py and generate_changelog.py make more than just one file, and it's not immediately obvious what they're for, until much later in the release steps on the wiki. Is it ok to put more information on these in Step 4 of the wiki?
3. The generated Wrye Bash Version History.html isn't up to date, because the template tail file doesn't have the latest changelog in it. I'd like to update the script to just take the current Version History, and insert the new changelog in the correct spot, rather than maintaining a second copy in the form of the tail text file (which needs to be updated every release). If that's OK with you, I'll do the necessary coding. Otherwise we need to add a step to the release guide to update the tail file.
4. Finally - I made the rel-305 branch for meta so any updated Wrye Bash program related stuff (dependencies, etc) would only get merged in once the release where they take effect is officially released. However, you've got plenty of work on the scripts going on there as well. So now I can't really merge to get your changes without also affecting the changes that shouldn't be put in place in master until the release. So, first part of the question, is your script related stuff in there ready to merge? And if so, do you mind if I merge only your stuff into master, then remake rel-305 with only those changes that need to go into effect on release? Also, we should come up with an agreement on how to handle the branches here then. I liked rel-* for changes that should only appear after a release, but if you have a better idea for naming that one. Then the sort of script work you have in rel-305 would be better in its own branch, maybe utumno-scripts, or just straight up commits to master, assuming no bugs. I'm not particularly picky about a messy master branch in this repo, since there won't be nearly as much going on as in the main repo.

[Utumno]

1. Please do - feel completely free to change anything btw. The editor is specified via a command line option (there is also a -no-editor flag) - I mention it in the repo readme (and script's usage) - use the mechanism in cli_parse.py with the actions to prompt the user maybe
2. see the readme on this repo again - feel free to edit the wiki - generate_version_history should generate one file but uses the changelogs generated by generate_changelog. Needs more comments apparently (edit: feel free to add more docs to methods (like return types and the like) - I admit I did a bad job there)
3. Perfectly fine - I had in mind that the changelogs stay in the repo so they are "stiched together" but apparently didn't write the code - do as you say
4. In short - take over rel-305 and merge it at will at master - yes merge the script changes they are stable apart from the things you mentioned. In the process please feel free to correct any unpythonisms, or design decisions I made or plain bugs. I should have named it utumno-rel-305 but I was alone here and expected the release to take much less time so I ended up with this messy rel-305 - I intended to rebase it a bit before merging - do or don't with my commits as you please

Re: branches - since we work together here now (though for the next couple weeks I won't commit anything here so you take over) let's follow the rules of the main repo with a grain of salt a la consenting adults and all that (so utumno-yadayada and yes rel- for rel specific stuff)

tldr: go over the scripts, make the changes to the version history one, maybe prompt the users for more options (like the editor) and merge the changes (edit: maybe simpler would be to just go on working on the rel-305 branch (run the scripts from there) and let me do the final rebase/merge so you don't have to deal with my commits - what's easier for you)

Sorry for the late reply - I am still off and on - will respond ASAP

[lojack5]

Ok, I've made some initial changes. I didn't want to go too much into it as I want to get this release out though.