Database update redux.

[zcskywire2]

Contains Phenom II and Athlon II CPUs, as well as a bunch of updated dates for various processors with the updated date formats.

[markasoftware]

I'm not sure why it's still showing all the old commits and the typo message, but I'm just gonna roll with it and hope it doesn't break anything. I feel really sorry for you doing this stuff on mobile. I'd still prefer the names (not just humanNames) to have meaningfulness on their own but I can fix it later, not a huge deal. You have a lot more patience than I do with this tedious stuff.

[markasoftware]

Hmm, i didn't sync up the beta branch to master somehow and now there's a weird duplicated commit thing. But it worked overall I think. There are now a grand total of 189 parts in SpecDB. You can view the beta stuff at https://beta.specdb.info/

[zcskywire2]

Those are rookie numbers, we've got to pump up those numbers. Don't know where I'm going next but there will be more to come

[markasoftware]

Before doing any more work, I'd highly recommend looking at this: https://stackoverflow.com/a/38641957/1233320

It explains what IMO is the best way to handle doing pull requests, and the most commonly used one. Basically, you have your "master" branch on the fork, which corresponds to a branch in the original repo (in this case, probably beta). You don't edit any files on this branch. When you want to make a PR, you create a branch, for example, phenom-athlon, and make your changes there. When you're done changing it, you do the PR, PR gets accepted, and then you pull the beta branch back down into your master branch. Then, if you want to do another PR, you create another branch off of your fork's master branch, which should always be identical to the original repo's branch that you're using (beta). I hope that makes sense.

You'll probably need to delete and recreate your fork to do this cleanly.

In terms of what work needs to be done in the future in terms of adding parts, there aren't very many GPUs currently, and APU support is coming soon as well. There are also some other things I'm planning to add which will require work to make them useful:

• More data fields: For example, we want things like freesync support, types of ports, crossfire support, etc for GPUs, feature support for CPUs (SSE, etc), and all that stuff. I'm planning to split the data table up into sections to make it easy for users to see only what they want to see while simultaneously having tons of rows.
• Variants: Still has a ways to go in terms of development, but we'll have support for "variants" of a part. The first thing this will be used for is GPUs, to represent different vendor versions. So, we could see the differences between the MSI Gaming edition of the RX 480 and the Sapphire Nitro one (e.g, cooling system, VRM configuration, what manufacturer they used for the PCB components, etc).

Thanks for your continued support of the project and all the parts you've added!

[zcskywire2]

Some other things that should be in CPU's while its on my head: Memory type, memory speed support, memory channels, max memory size, die size (including multi die support ex Epyc = 4 x 232 sq mm). instruction set, steeping. And perhaps as support is expanded, splitting AMD-CPUs into Desktop CPU, Laptop CPU, Server CPU, as the the number of supported processors grow.. Probably heading into Opteron support after Phenom I. Perhaps I will flesh out some Polaris parts as well I have also reorganized my branches to be more inline with that github practice.