So, I'm supposed to release tomorrow...
Today, I changed another set of files (/cache became /gz, and /css and /js were integrated into it), because I didn't like having so many root folders just for caching.
I also screwed up another commit, with a change that was too random and broke other stuff. In the future, these changes will be reverted the usual way, but I much prefer being able to amend a commit. I'll just have to learn, I guess, that I shouldn't push until everything's tested...
My main issue is with the update process. Now I have this /core folder where I log into. Then I have to determine what files I should update. I'm totally lost, because the folder names are no longer distinguished by starting with an uppercase char or something like that.
Voilà. I just don't like the new update process. I find it harder, or longer, than the previous one. But I can't revert either, because this new folder structure has some actual *meaning*. I wanted to remove themes, so I'll have to live with the fact that I can't rely on the Themes folder structure any more.
Believe me... It's hard.
And tomorrow, I'm supposed to set the database structure in stone. I'm supposed to say, "okay, I'll never change it anymore, except for big additions for which I'll write some sort of script."
But the more I look at the SQL file, the more I find things to change.
For instance, MySQL 5.0.3 supports the BIT data format. Ever heard about that..? Me neither. TINYINT(1) is used for booleans in Wedge (and SMF), but it still uses one byte per entry. The BIT(1) format allows the use of 8 times less space. So, yes, it's VERY tempting to start using BIT(1) everywhere, since Wedge will always support it... But... There's a but... WHAT if one of these columns actually has more than two values? Like, for instance, "wedge_screwed_up.IamABoolean = (0, 1, 2)", where "2" was added by a SMF developer to account for a problem that couldn't be solved with binary thinking. It still fits into TINYINT, but not into BIT. Making it prone to bugs in Wedge.
There are dozens of TINYINTs, and I don't know if it's worth double-checking every table to make sure it doesn't use these columns in a weird way.
I can always change everything to BIT(1) later, little by little, but...
It just goes to show that I don't feel ready for a public release. Really, really, I feel like I'm freezing.
Today, I changed another set of files (/cache became /gz, and /css and /js were integrated into it), because I didn't like having so many root folders just for caching.
I also screwed up another commit, with a change that was too random and broke other stuff. In the future, these changes will be reverted the usual way, but I much prefer being able to amend a commit. I'll just have to learn, I guess, that I shouldn't push until everything's tested...
My main issue is with the update process. Now I have this /core folder where I log into. Then I have to determine what files I should update. I'm totally lost, because the folder names are no longer distinguished by starting with an uppercase char or something like that.
Voilà. I just don't like the new update process. I find it harder, or longer, than the previous one. But I can't revert either, because this new folder structure has some actual *meaning*. I wanted to remove themes, so I'll have to live with the fact that I can't rely on the Themes folder structure any more.
Believe me... It's hard.
And tomorrow, I'm supposed to set the database structure in stone. I'm supposed to say, "okay, I'll never change it anymore, except for big additions for which I'll write some sort of script."
But the more I look at the SQL file, the more I find things to change.
For instance, MySQL 5.0.3 supports the BIT data format. Ever heard about that..? Me neither. TINYINT(1) is used for booleans in Wedge (and SMF), but it still uses one byte per entry. The BIT(1) format allows the use of 8 times less space. So, yes, it's VERY tempting to start using BIT(1) everywhere, since Wedge will always support it... But... There's a but... WHAT if one of these columns actually has more than two values? Like, for instance, "wedge_screwed_up.IamABoolean = (0, 1, 2)", where "2" was added by a SMF developer to account for a problem that couldn't be solved with binary thinking. It still fits into TINYINT, but not into BIT. Making it prone to bugs in Wedge.
There are dozens of TINYINTs, and I don't know if it's worth double-checking every table to make sure it doesn't use these columns in a weird way.
I can always change everything to BIT(1) later, little by little, but...
It just goes to show that I don't feel ready for a public release. Really, really, I feel like I'm freezing.