These are a couple of suggestions that will make the upgrade process much easier and faster for webmasters.
1st: Do not make changes to the DB structure in between minor versions. The other day, I had to upgrade a forum running 1.2.2 to 1.2.5 and I thought: "well, it's only 3 minor versions (patches)" so I forgot to execute the script to upgrade the database. I was a bit scared when I saw that the forum was giving a nice error complaining about a field in the database when the users were logged in. In fact, I didn't spect that error. Of course the error was gone as soon as I updated the DB, but I'd suggest to increase a second number each time the DB structure is modified (like from 1.2.2 to 1.3.0, or whatever). Also, apart form this, if it's possible, keep to the minimun the changes in the database.
2nd: Remove all the "$Id:....$" tags of the PHP files. Those tags change in each version of the repository and they just give conficts when merging 2 versions, or when a webmaster, who has modified some files of MyBB, wants to update and wants to check which files have changed. I think that those tags are more a hindrance than a help.
Thanks.
Choli Wrote:These are a couple of suggestions that will make the upgrade process much easier and faster for webmasters.
1st: Do not make changes to the DB structure in between minor versions. The other day, I had to upgrade a forum running 1.2.2 to 1.2.5 and I thought: "well, it's only 3 minor versions (patches)" so I forgot to execute the script to upgrade the database. I was a bit scared when I saw that the forum was giving a nice error complaining about a field in the database when the users were logged in. In fact, I didn't spect that error. Of course the error was gone as soon as I updated the DB, but I'd suggest to increase a second number each time the DB structure is modified (like from 1.2.2 to 1.3.0, or whatever). Also, apart form this, if it's possible, keep to the minimun the changes in the database.
What if the change is needed for a bug fix?
If you forget it it's not our fault.
Choli Wrote:2nd: Remove all the "$Id:....$" tags of the PHP files. Those tags change in each version of the repository and they just give conficts when merging 2 versions, or when a webmaster, who has modified some files of MyBB, wants to update and wants to check which files have changed. I think that those tags are more a hindrance than a help.
Thanks.
It helps us determine which file were changed when. Then we can trackback the changes in our svn.. It might hinder you but not us. And one more change isn't really that much. You should be able to update with these small changes in just a couple of minutes.
I never had a problem with it if you follow the instructions they provide and if I do ever have a problem and I ask here they are gladly able to assist.
CraKteR Wrote:What if the change is needed for a bug fix?
If you forget it it's not our fault.
Of course it's not your fault, sorry if i explained it wrong. I just meant that as far as possible not to introduce changes in the DB in minor versions
Quote:It helps us determine which file were changed when. Then we can trackback the changes in our svn.. It might hinder you but not us. And one more change isn't really that much. You should be able to update with these small changes in just a couple of minutes.
The problem is not that additional change. It's one file more changed. I mean: If you compare the files of 1.2.2 with 1.2.5, you'll see that nearly all files are modified. Then you check the changes and more than a half of them have changes only in that line ($Id...$). This is an extra work for webmasters when they want to apply their changes/mods of a version to a newer one.
I know this is just several points of view, or ways of working. Maybe I like more the idea of not having those tags because in my company we work in that way. And to know the changes of a file, we use the tools of cvs (it'd be svn in your case). We keep track of the changes of each internal version in a changelog.txt file and we tag each version.
Anyway, thanks for your comments
Choli Wrote:CraKteR Wrote:What if the change is needed for a bug fix?
If you forget it it's not our fault.
Of course it's not your fault, sorry if i explained it wrong. I just meant that as far as possible not to introduce changes in the DB in minor versions
We wouldn't make a change to the database structure if it wasn't needed though.
Choli Wrote:Quote:It helps us determine which file were changed when. Then we can trackback the changes in our svn.. It might hinder you but not us. And one more change isn't really that much. You should be able to update with these small changes in just a couple of minutes.
The problem is not that additional change. It's one file more changed. I mean: If you compare the files of 1.2.2 with 1.2.5, you'll see that nearly all files are modified. Then you check the changes and more than a half of them have changes only in that line ($Id...$). This is an extra work for webmasters when they want to apply their changes/mods of a version to a newer one.
I know this is just several points of view, or ways of working. Maybe I like more the idea of not having those tags because in my company we work in that way. And to know the changes of a file, we use the tools of cvs (it'd be svn in your case). We keep track of the changes of each internal version in a changelog.txt file and we tag each version.
Anyway, thanks for your comments
It would only take like a minute longer to check those files though. I don't see it as that much. And we usually write a list of which files were changed in the releases.
Choli Wrote:CraKteR Wrote:What if the change is needed for a bug fix?
If you forget it it's not our fault.
Of course it's not your fault, sorry if i explained it wrong. I just meant that as far as possible not to introduce changes in the DB in minor versions
Quote:It helps us determine which file were changed when. Then we can trackback the changes in our svn.. It might hinder you but not us. And one more change isn't really that much. You should be able to update with these small changes in just a couple of minutes.
The problem is not that additional change. It's one file more changed. I mean: If you compare the files of 1.2.2 with 1.2.5, you'll see that nearly all files are modified. Then you check the changes and more than a half of them have changes only in that line ($Id...$). This is an extra work for webmasters when they want to apply their changes/mods of a version to a newer one.
I know this is just several points of view, or ways of working. Maybe I like more the idea of not having those tags because in my company we work in that way. And to know the changes of a file, we use the tools of cvs (it'd be svn in your case). We keep track of the changes of each internal version in a changelog.txt file and we tag each version.
Anyway, thanks for your comments
You know you can ignore lines that start with * $Id in most merge programs. So technically, if you know what your doing it's not a problem, and second, you don't need to update that line and third, it's there for good reasons.
As for the database changes, people want the bug fixed asap, others would wait. How can we please both parties? And we decided that it would be better to just fix it right then and their.
(The $Id$ lines are also used here for support to determine which version of a file a user is using - I've requested them several times)