I'm running ISPConfig v3.2.2 on a primary server and have 3.2.0 on a secondary. These are the only two systems at this time. The configuration has been running with no apparent issues related to ISPConfig, but it's time to move forward. The plan is to replace the secondary server hardware. Possible approach to upgrade (#1): - Update secondary1 to v3.2.2 to get the systems to agree. - Add and configure a new secondary2 with v3.2.2. - Remove secondary1 and change name/IP/certs to replace it with secondary2. Why update the secondary? So that the new secondary2 will have the same version as secondary1. That eliminates potential version-related issues. Possible approach to upgrade (#2): - Add and configure a new secondary2 with v3.2.8. - Remove secondary1 and change name/IP/certs to replace it with secondary2. Will there be any issues with the v3.2.2 primary and the v3.2.8 secondary? Possible approach to upgrade (#3): - Update primary to v3.2.8. - Add and configure a new secondary2 with v3.2.8. - Remove secondary1 and change name/IP/certs to replace it with secondary2. From forum notes here, I don't think there will be issues with a direct jump from 3.2.2 to 3.2.8. Any advice? Any issues with running master/slave with different versions? Internally, are those issues abstracted outside of the sys_datalog interface? When this is complete we'll be ready to add more systems into this network. Oh boy! Thanks!
There should be. ISPConfig multiserver setup is supposed to run same version of ISPCconfig on all nodes. If you have or are going to have multiple hosts, perhaps set up a two node ISPConfig with latest ISPConfig, then use migration tool to migrate old system to that? This way you do not need to mess up the old working system with upgrades, and get to ISPConfig 3.2.8p1.
Thanks as always, @Taleman ! It makes perfect sense that the versions should be the same. As you know, in many environments the differences between point-releases are often minor enough to allow interoperability. Given this situation I'm hoping a review of the versioning might be considered, where compatible versions are in a x.y.z point-release, and incompatible versions are bumped to a new minor version x.y ID. I would be very happy to use Migration Tool for migrating both slave and master to new/upgraded homes. Where is the best place for pre-sales Q&A for Migration Tool?
This makes no sense for ISPconfig as we do not make a release for every single change or bugfix, and the bundled bugfix and feature release that we do every few months always require that you have the same version as they always contain database changes. And in ISPConfig numbering scheme, the first three numbers define a major release, so e.g. 3.2.8 is a major release. 3.2.8p1 would be a minor release of 3.2.8. But even for minor release, I won't use different versions.
You can e.g. post your questions here: https://forum.howtoforge.com/forums/plugins-modules-addons.34/
That's the detail that I was seeking. I don't think I've read anywhere that updates are "always" different enough from the previous version, such that simultaneous update of all systems in a ISPConfig network is required for each update. I didn't imply that. I was suggesting "z" releases for any batch of changes that are compatible within x.y, and bumping "y" for incompatible changes that require network updates. Example: 5.6.0, 5.6.1, 5.6.2 ... all compatible because there are no breaking changes, any 5.6.x should work with any other. But 5.7.0 tells everyone that some detail includes a breaking (fixing) change that requires all systems to be at the same 5.7.x level. Some software is written like this. I didn't know if ISPConfig was. You know because you do the versioning. Now I and everyone else knows how this software's versioning works. After looking at new details I probably don't need to replace either of these systems, but just need to upgrade them both to 3.2.8. However, this thread will help when the need arises (for anyone) to replace one or more servers. Thanks.
