| Author |
|
gg102
Senior Member
Joined: January 29 2013
Location: United States
Online Status: Offline
Posts: 245
|
| Posted: January 09 2015 at 13:13 | IP Logged
|
|
|
Dave,
In my observation, I'm seeing that PH is getting to a point where it's no longer a hobbyist toy, but rather has become a serious, (failure-is-not-an-option) home running, IOT (Internet of things) contender. Because of this, and because NOT everyone using PH is a high powered programmer, it may be time to begin the process taking sections of PH and making them more user friendly (idiot proof).
The installation/upgrade process may be a good place to start. You have done a lot of work to clean up the installation process and it runs very smoothly now. I'd like to suggest for the future, to have an installation question: "Fresh Installation or UPGRADE". If the user selects upgrade, the process would make its own backup copy to a known place, and do the upgrade, then copy back the prior .ini files, WEB directory, buttons, graphics, or whatever it needs. This way an upgrade is more 'painless' (euphemism for idiot proof). You might get less trouble calls related to copying previous ini or config files. You might also ask a question, "install speech system" which would install (or re-install) the mschapi or whatever...... Other optional installation subsystems could also be asked/installed. Or, maybe just install them anyway. They are not THAT big, and machines are big enough these days that it doesn't matter. (Please ask them up front, maybe use check boxes)
If there is a database upgrade, you could just call the database upgrade .exe and NOT pray that the user does it correctly. If a user is upgrading from an incompatible version (see below) that's NOT something that the upgrade can do PERIOD. Don't worry about that. In that case, they can upgrade 'by hand' or do the intermediate upgrades. You could "draw the line" at 2.1.5x.
People don't care how long an upgrade takes, just be verbose about what's happening so people know it's still working.
For a fresh installation, you could ask some of the .ini questions and do some of the setup during the installation.
In addition, you could ask for directories, while allowing for defaults. The graphics directory(s) could be asked during installation (for buttons, backgrounds, user images, lines, and all those buttons in the CC could be "repaired" with the new directory so in the CC, the programmer need only enter the name of the graphic and not the whole path. (ok, maybe in the CC have a separate col for the directory and graphic.)
The reason I'm suggestion this is because as I read these forums, I'm seeing questions who's solutions are related to the installation process. It might save you some work if you head-off these questions by making the installation/upgrade process more bullet proof (another euphemism for idiot proof).
It might be a little more work up front, but in the long run, you may save some support questions.
I don't know if you have thought about the version number scheme. I'd offer:
x.x.xxxx
| | |
| | +--minor bug fixes
| +----internal structural changes/incompatibility changes
+------Major user interface changes/incompatibility changes
When you went from 2.1.4 to 2.1.5 you probably should have gone to 3.x.x because of the new database.
2.1.5a should have been 3.0.2
2.1.5b should have been 3.0.3
2.1.5c should have been 3.0.4
Adding functions-function/calls would increment the middle number as this version would be incompatible with the previous version. If I wrote my app in 3.0.x it would run in 3.1.x. If I wrote my app in 3.1.x it might not run in 3.0.x because some functions could be missing or changed.
If you do the installation upgrade as I offered, you could do a major version change at that point so you can distinguish it on a go-forward basis.
Maybe you know someone you can offload this to as this is a separate process.
No requirements, I'm just observing......
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: January 09 2015 at 16:37 | IP Logged
|
|
|
gg,
Definitely agree with you on the installation/upgrade process. I'll have to do some more exploration of the Inno setup installer that Im using now and see how I can make things easier and more bullet-proof. I also need to rewrite the wizards (which have been disabled other than the CC wizard on versions after 2.1b).
I'll have to take a look at your suggestions for versioning. Currently a "release" version is using an X.X version number with the first X being for major changes/new features and the second X for more incremental changes. An X.X.X version denotes a "beta" version and is usually in preparation for a new "release" version where I'll be rolling either the major or minor version depending upon the actual changes. I usually go through several x.x.x beta's until everything is settled out and stable and then pretty much wrap the last beta and recompile to the release version number. For incremental bug fixes within a beta, I'll usually add a letter like you see in the 2.1.5a version. This is essentially the same as 2.1.5 (should be no new features) and just fixing some bugs. On very rare occasion, I have released an x.x.x.x version which would be an alpha for testing purposes.
Once 2.1.5 stabilizes and assuming I don't have a 2.1.6, then the next release version would probably be 2.2 (no major changes since 2.1b and more of what I call incremental changes). When I get the z-wave support added, then the first release version would be 3.0.
Of course, PowerHome has been around for over 15 years so perhaps my versioning method is a bit too slow and I need to step up my system  . I hadnt thought about including compatibility as a factor in my scheme.
I'll definitely be putting some thought into it.
Appreciate the comments,
Dave.
|
| Back to Top |
|
| |
|
|
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: Upgrading discussion...
