# Daml upgrade and duplicate modules during codegen **URL:** \ **Category:** App Development\ **Tags:** upgrade, codegen, java\ **Created:** [August 3, 2022, 2:13pm UTC](https://forum.canton.network/t/daml-upgrade-and-duplicate-modules-during-codegen/5019 "2022-08-03T14:13:10Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![Stephen](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/stephen/32/102_2.png) [@Stephen](https://forum.canton.network/u/Stephen)\ **Post date:** [August 3, 2022, 2:58pm UTC](https://forum.canton.network/t/daml-upgrade-and-duplicate-modules-during-codegen/5019/2 "2022-08-03T14:58:35Z")
I suggest introducing a unique `module-prefix` for `v1` and each future version. This is stable with respect to current references to `v0`, and defines a path that will remain stable for `v1` immediately as you introduce it, and with each future version as well. > [@Thibault](#): > > not really for Utils which hasn’t changed, but all references to it in the code now need to be updated The problem with placing unchanging modules in the same package as changing modules is that, fundamentally, they _all_ change. In the topology you’ve described, `Utils` all get new package IDs to go along. That makes them distinct with respect to the ledger API, which is more-or-less the primary target of codegen, and means that dealing with that distinction is something you cannot avoid. Having two generated copies of `Utils` is the most straightforward way of being able to deal with that distinction. If you want `Utils` to “not change”, then it genuinely needs to be in a separate Daml package, not just a separate module. We split up the standard library for a similar reason: > [@Should we maintain a daml 'base' or 'prelude-next' library?](https://discuss.daml.com/t/should-we-maintain-a-daml-base-or-prelude-next-library/1576/4): > > I’d like to add one more point to think about: You probably don’t want to have any data types that are intended to end up on a ledger in such a library. If you change your library or have to recompile it with a different version of the SDK, you will end up with a different package ID and hence the types are considered different. For daml-stdlib, we jump through quite some hoops to get stable names for type like Either. More precisely, we put each such type in its own package without anything el… For the same reason, we recommend putting triggers, scripts, and such in separate packages, so that they can be altered with reckless abandon without having any on-ledger implications. --- _[View the full topic](https://forum.canton.network/t/daml-upgrade-and-duplicate-modules-during-codegen/5019)._