Our team has versioning enabled for modules, and we love it and depend on it.
We'd really like to be able to select what version of a module to use.
Say, for example, a module on version 1.7.3 is being used by an app, and then we make another app using the same module. The new app needs a new breaking change feature on the module, so we do the changes and make a 2.0.0 release.
Now the previous app also uses the 2.0.0, instead of 1.7.3 - breaking the app!
We have the exact same use case, though we'd also like to be able to tie module versions to app versions, rather than different apps.
Pleease, update it. It's just so hacky to try to use modules as is. We need to duplicate modules in order to do this. There's no way to proper version modules.
Up
Up
Up
Up
Up!
Up!
In need of this feature as well, thanks for your help
We've got this requirement too, it's very difficult to use modules in an App without being able to control upgrades to them through test and prod environments
@Michael_Stone I will add your +1 to the feature request ticket as well. Apologies for the inconvenience. We are working to make modules easier to use and iterate on and we appreciate the feedback!
Seems hard to believe this feature is still floating around on the backlog. Modules are very difficult to manage without version pinning and it causes a lot of problems for our automated test suites.
Is there any rough ETA on when version pinning might be available?
Hi @dennis_nimblerx,
Apologies for the inconvenience. I had been hoping that this ticket would have gotten more traction but I can follow up on this with our source control team to see where they stand.
Could you elaborate more on the problems being caused with the automated test suites?
My first thought was that adopting a naming convention to have modules contain some reference to their minor or major patch version which they correspond to.
Also for our road map we have an AI copilot feature coming, which will be able to build modules or equivalent clusters of components coming which should hopefully help with this issue.
I will follow up with any news I hear from the source control team as well in the short term for their roadmap and what best practices using modules from their perspective are. Let me know any and all additional details on your use case and how your team is building with test suites and app versioning!
Thanks for the response, @Jack_T. The idea about naming modules by version may alleviate some pain here. It's not ideal to have several copies of the same module as a psuedo-versioning scheme, but I think it would work.
The core issue with automated test suites is even when changes to a module are benign in terms of end user functionality, they often lead to broken end to end tests and developers don't realize they may be affecting more than one app with their changes.
No problem @dennis_nimblerx 
Is there a reason why there are several copies of the same module? Once you create a module, you can re-use it over multiple apps.
It sounds like your team is heavily using modules, with many small abstractions over the same foundational set ups. It might be better to use stand alone components for iterating and developing.
Modules are primarily made for simple reusable boilerplate such as headers/footers or forms/modals. Using components will allow for versioning at the app level which better follows multi-developer best practices for testing out changes and iterating on apps. Which touches on your last point about developers making changes that effect others. As this can be better controlled and mitigated with app level versioning and branching.