Now a colleague told me that there is possibility to add multiple components in that single input, I have never noticed that prompt in the input or didn't believe it. :D So point 2 is already available, but it could have better UI - a checklist instead of an autocomplete. I am sometimes not sure that I have recalled all needed names to add, and start entering just A to Z to see what's there.

Point 3. is particularly useful for on-premises platform upgrades, otherwise I feel the way forward when it comes to deploying between environments would be by enhancing the experience and feature set of LifeTime, and the need for dependency refreshes by publishing a solution should mostly be addressed with a better application architecture wouldn't you agree?

Jorge, regarding LifeTime - not only it's more difficult to use, sometimes it can not be used at all. For example, when you have one dev and several test environments - only one chain can be configured in LT. We had other cases when LT could not do it properly.

I don't really understand how you relate dependencies refresh to architecture. Recently, we have put huge effort into improving architecture. As a result, refreshing dependencies became only harder because now we have several times more modules. Even if you don't have braking interface changes - you still need to republish upper modules for the changes in lower to be applied. Off course you can spend time to check usages and manually publish consumer modules after every change, but there is easier and more mistake-prone way: solution deployment. If you can automate things - why would you do it manually?

It's always good to deploy solution in the end of the day when everybody has finished work, and for automatic tests run in the night to be up-to-date. Unfortunately, there is no built-in way to deploy solution automatically by timer, but at least with just few clicks you can do it. Now I think I should have put this into the list also:

4. Possibility to configure solution to be deployed automatically by timer.

Regarding LifeTime, saying that LT is more difficult to use seems... odd to me, as it is meant to make the DevOps life easier. It is designed to make sure that deployment of applications between environments is safe: pre-checks that existing applications on the target environment won't break (because they were based on older incompatible versions of your modules that would be updated by the deployment) nor are broken applications installed (because they depend on a version of a module that was not installed/updated on the target environment).

What I meant with solving it with a better architecture is that if your applications follow a good architecture, only modules that really consume the concepts you've updated will be affected (less dependencies you need to refresh when you modify producers). Also, when using LifeTime with an environment with good architecture design, your application dependencies are also easier to manage (smaller applications, each one with less consumers). Another way to tackle the dependency refresh concerns could be to use Service Applications to reduce the strong dependency between modules, updating a producer would not require publishing a consumer for the latest version of the publisher to be used (unless you changed the interface)

I understand the consideration about multiple "lanes" for LT, that is clearly something you would currently need a solution for.

When it comes to the dependencies refresh, I guess it will depend on the situation, mostly I would rather make sure that the changes made in a producer module are propagated to consumers and check whether they break the consumer's logic or not. Your approach is assuming everything will be fine and there are no breaking changes... that one you could automate, and a Solution would probably be the right approach. 

Concerning your point 4., there are undocumented/unsupported APIs that allow you to publish existing solutions programatically. If you could use LifeTime, it also has APIs to manage deployments (and you can choose the applications to include in the deployment).

Jorge,

1. But LifeTime is harder. It's really frustrating to need to click hundred times to start it (this is my old idea https://www.outsystems.com/ideas/3137/select-all-in-lifetime-applications-to-deploy ). Also it sometimes gives strange errors which don't exist in reality, but won't let you continue. I remember we also had problems when there were architecture changes (modules renamed and moved between apps). I think the only thing which makes it better than solutions is that you can select part of the stack, with solutions it's more difficult because you need to prepare another solution and be sure to include correct modules into it.

2. "only modules that really consume the concepts you've updated will be affected" - sorry, I am not single developer doing small change once per day. We have a team and we are doing big amount of changes every day, often we have almost all core modules changed during the day. And yes, as I said, you can still go and update consumers manually, but why would you want to do it? Even if there are 2 or 3 of them. "Your approach is assuming everything will be fine" - no, it's not about assuming, it's about getting things fresh and up-to-date. If there are no problems - fine, if there are - that's also a result. It's like "rebuild solution" option in MS Visual Studio. Imagine if you advised me, instead of building full VS solution, or using proper build scripts - to go open projects separately in the correct order and build them.

3. "undocumented/unsupported APIs " - yes, I know, we have even built one auto-builder module, but that doesn't work and it's not clear why. Off course it's difficult because it's undocumented and unsupported. :D I want to look for some other ways, but didn't have time yet.

Frankly I don't understand why we are even discussing it. These processes must be automated, no matter if you have good architecture or not, if you are smart or stupid - you just don't need to spend human time on this kind of tasks. I remember when I was young OS developer I didn't know about solutions and whenever I changed something - I had to go through all consumers, open there references and check/refresh... Then before deployment, had to go though all modules to be sure... Than those click-click-clicks in LifeTime just to select everything... Then it gives error ans you start over again... When I found out about solutions - it was such a relief! I didn't have to do that stupid robot work any more.

I created by own application to add espaces to solutions.  We do have access to the entities under (System).

Regarding the 2nd point I would like to suggest a wild card to catch all the modules that includes a sub-string, likewise the command 'like' in SQL (e.g. '%_Theme' or '%_API')

Once it's common the usage a naming convention on Modules that will be very useful.