none
GoToMeeting install with different versions

    Question

  • Having trouble wrapping my head around this one.

    We want to start making gotomeeting available in the software center for users to self install.

    There are a couple things we want to accomplish but having issues thanks to gotomeeting's design.

    1. If a user installs gotomeeting from the software center and a new version is released they will automatically have the new version installed and the old version stays installed as well.

    2. If a user installs gotomeeting it also installs all of the old versions we have listed/available.

    Thinking about the solution, I also need to update this often as gotomeeting seems to be updated frequently.  I tried superscedence, but don't think that's the way to go.  If I create dependencies, can I create a chain of them, ie v4 is dependent on v3 which is dependent on v2 etc and all of them will install back from the first dependency?

    Am I going to have to make a collection for "has gotomeeting installed" and force the newest versions to those computers?

    Thursday, March 21, 2013 2:53 PM

Answers

  • Found this - http://community.gotomeeting.com/gotomeeting/topics/which_version_of_gotomeeting_needs_to_be_installed

    From what they've said, they are working on a solution to make the client backwards compatible and multiversion install.

    To solve your current problem, you have 2 choices I can think of:

    1) Use dependency chaining. When a new version comes along you link the chain. For existing installs, you will need to deploy it to the machines. Unfortunately, supersedence won't work for your situation as you require the old versions to remain.

    2) Use supersedence. When the new version comes along you create a multi-install package with all of the versions. When you supersede the old package, the old versions will be uninstalled from machines and all the versions included in the new package will install. 

    Note - "As designed" for some reason (someone please explain why), you can't have 2 applications with the same name but different versions. You need to have a unique name which contains the version number, which isn't great for reporting..

    Good luck! Report back if you need more info.

    • Marked as answer by Garber Mark Friday, March 22, 2013 2:20 PM
    Friday, March 22, 2013 5:52 AM

All replies

  • Not totally familiar with GoToMeeting...but do have a few clarifying questions here...

    If you install the App outside of the Software Center, does it install the same way (does it leave behind older versions)?

    If that is the case, then there is nothing you can do about that (unless you want to do the work yourself).  What type of install is this anyway?  MSI, EXE?

    I don't quite understand how when a user installs it from the Catalog that they get all the old versions too.  What's going on with that?  How are you packaging this thing up?  That seems odd to me.


    Mike...

    Thursday, March 21, 2013 9:29 PM
  • Sorry, let me clarify.

    If you install outside of software center it does not remove the old version, which is what is wanted.

    It is an MSI install.

    We want it to install all of the old versions.

    Backstory, gotomeeting has different versions on their servers and companies can choose which version to run.  The client side is only compatible with the matching server version.  So seemingly anytime a user needs to access gotomeeting, they are needing admin permissions to install because it is always a different version.

    What I want is to be able to install 3 old versions plus the current version anytime a user installs through the catalog.  Keeping in mind that I will need to update soon and have it be 4 old versions plus the current version AND when I put the new version in, anyone who has installed gets it automatically.

    Thursday, March 21, 2013 9:35 PM
  • Found this - http://community.gotomeeting.com/gotomeeting/topics/which_version_of_gotomeeting_needs_to_be_installed

    From what they've said, they are working on a solution to make the client backwards compatible and multiversion install.

    To solve your current problem, you have 2 choices I can think of:

    1) Use dependency chaining. When a new version comes along you link the chain. For existing installs, you will need to deploy it to the machines. Unfortunately, supersedence won't work for your situation as you require the old versions to remain.

    2) Use supersedence. When the new version comes along you create a multi-install package with all of the versions. When you supersede the old package, the old versions will be uninstalled from machines and all the versions included in the new package will install. 

    Note - "As designed" for some reason (someone please explain why), you can't have 2 applications with the same name but different versions. You need to have a unique name which contains the version number, which isn't great for reporting..

    Good luck! Report back if you need more info.

    • Marked as answer by Garber Mark Friday, March 22, 2013 2:20 PM
    Friday, March 22, 2013 5:52 AM
  • Solutions like "dependency chaining" are a little more than I was bargaining for (though it sounds like it would work). I've been using RHUB's setup, and fortunately, I haven't run into any complications like this...
    Monday, September 30, 2013 9:16 AM