1. Simplification of wpcdenv/imasenv schema

1.1. Current solution

The initial request was to enable users to set-up working environment easily providing possibility of choosing:

• compiler (and its version)
• DataDictionary version
• Access Layer version
• a versions of other of libraries used by WPCD developers

As a result of discussions two steps (wpcdenv/imasenv) schema was introduced, to provide a freedom of choice and  not to make module name too complicated (like imasenv/3.24.0/intel/18.0/ual/4.1.5/wpcdenv/4.0)

• wpcdenv (e.g. wpcdenv/intel/18.0/1.1) sets compiler, its versions and loads all DD/IMAS independent libraries (e.g. blitz, lapack, xmllib)
• imasenv (e.g. imasenv/3.24.0/ual/4.1.5/1.1) sets IMAS for given DD version and loads all DD/IMAS dependent libraries  (e.g. ggd, amns)

1.2. Lesson learned

After one year, since it's initial design, I decided to evaluate wpcdenv/imasenv scenario. Outcome of evaluation:

• in most cases users specify only "module load imasenv"  or "module load imasenv/<dd-ver> "
• UAL is a "yet another library" that don't has to be set separately ("ual/<al-version>" part of schema)
• users usually don't take into account AL version and other libs version... and use defaults 
• there is a need to couple imasenv with particular wpcdenv version:
  • currently imasenv loads default wpcdenv
  • all imasenv libraries can be not compatible with other wpcdenv version as being used during compilation
  • loading manually wpcdenv by user and than imasenv can result in inconsistent environment 

1.3. Simplification

Propositions to simplify mechanism for setting working environment base on initial David C. suggestions (yes, Dave, I should follow your hints):

• to remove "ual/<al-version>" part

• to combine wpcdenv and imasenv within one module 

  imasenv/<dd-ver>/<compiler>/<compiler-ver>/<library-set-ver>
  e.g.:
  imasenv/3.24.0/intel/17.0/1.0.2

Justification:

• Proposed schema is simplification (from users point of view) of existing mechanism
• (already mentioned) no need to handle AL differently than other libraries
• It solves problem of coupling libraries and its dependencies used at compilation time (aka a correct wpcdenv for given imasenv)
• The change will be transparent for the users that loads defaults calling "module load imasenv[/dd-ver]" 

2. Lifecycle

2.1. Tagged version

• Tagged version of module, used by some tagged version(s) of  CD product(s)
• Must be well tested  and stable 
• This version is intended to use mainly by users , to provide them stable environment for running  CD product(s) 
• The chosen tagged version (in most cases the latest one) is set as default  one

2.2. Release candidate (RC)

• A candidate for a next tagged version
• Provides a common, unified environment for developers working on next version of given CD product 
• A RC version should be stable, however it would be changed quite often (patches, new functionality of libraries) so it may happen that RC version will have some issues
• Once WPCD confirms that its product works fine, RC is tagged 

2.3. Alpha version

• A candidate for a next tagged version
• Introduced to make sure that update/change requested by developer(s) is "safe"  and will not brake environment (used by large group of developers)
• Used by a limited group of testers (usually by person who request change plus one/two other testers)
• Used for limited amount of time (omne, two days)
• If tests are passed, changes are introduced to RC:
  • patches automatically
  • library updates (that may change APIs) after confirmation coming from WPCD
• BTW: Alpha version is an equivalent of "module load imasenv/x.y.z/rc; module switch tested-lib/tested-ver"