Historically, users could choose which version of an executable they'd want. More recently we developed more complex applications and I'm kind of trying to explain why this can't, IMO, not work for users to choose a version. My colleague wants to keep using the version tool we have but I think it can't be applied.
Users could choose which version to use. It's not clear why you would need a "version tool", why you would use "software configuration management" and "configuration management software", when (as you describe it) "everyone is on a terminal launching jobs".
The end user simply wants to use version X or Y (1 or 2) of a particular program because that's what works for them - either it's what they know how to use or it's what works with their data format or other programs.
If they are clicking a desktop icon or typing on the command line they'll have to get used to the fact that there'll be a number on the end of the name or you'll have to set up their computer so that they type (or click) just a name (no number) and what comes up is what they arranged for.
As support staff you'll have to choose between supporting multiple versions and hopefully answering few questions or training some of your employees on the newest version and suffering with the learning curve and complaints.
So how would you distinguish programs that can be used with a specific version and others that can't. Are there any terms to speak about it? Am I missing something?
Always supply the newest stable version for the user and develop training ahead of time for the next version you want to switch them to (after it is stable). With open source software that's not too difficult, with closed source proprietary software you probably won't have access to early releases and there will be a lag between learning and productivity (should you decide to upgrade).
The end user (and the owner of the business) just wants to do the work and get it done. Presumably you will be more efficient by doing less work (less fixing and less support) while the end user is more efficient by doing more work.
So you'll want to decide the balance between fixing, teaching, and upgrading - and prepare a plan that allocates the correct amount of resources to each part, with the goal of decreasing the amount of work, and especially duplication (redoing) of work.
How would you stress out the problems that can occur if users start using older versions knowing that this will increase the time spend giving support to users, telling them to upgrade, etc.
See above.
P.S.: In this application context, we have full responsibility for retro-compatibility.
Edit : For more context, i work in a scientific environment where everyone is on a terminal launching jobs.
From a comment:
Where's the line between offering a "pick a version" or not? How do you decide on this? What makes a program a good candidate for one or the other? – Pobe yesterday
Plan what works best for your department (less work and complaints) and what works best for the company (less complaining and more work done).
Keep it simple, but keep it working and the versions used recent. Decide if there's a good reason to upgrade to the newest version and develop a plan to advance forward together.
PS: I always use the bleeding edge version and leave the office on the latest working version until it's unproductive for them to be behind, then I sell the owner (whom often is also using a newer version than the rest of the office) on some training time to move everyone forward.
If there's some reason to support legacy systems (for the sake of some customers) then maybe you need to seperate part of your employees into two groups, one group just does the work that comes in and a specialist team that supports customers with special requirements (for premium rates).
