# Project packaging

**URL:** <https://forum.inductiveautomation.com/t/project-packaging/80202>\
**Category:** Ignition\
**Tags:** ignition81\
**Created:** [October 9, 2023, 1:44pm UTC](https://forum.inductiveautomation.com/t/project-packaging/80202 "2023-10-09T13:44:26Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![louagejasper](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/louagejasper/32/86311_2.png) [@louagejasper](https://forum.inductiveautomation.com/u/louagejasper)\
**Post date:** [October 9, 2023, 1:44pm UTC](https://forum.inductiveautomation.com/t/project-packaging/80202/1 "2023-10-09T13:44:26Z")

</div>

Hi all,

Our Ignition projects are organized like this:  
We have 1 parent 'lib' project, and then a few children projects underneath, often different teams managing other children-projects.

However, lately, we get this question more often: Can we make it so our 'lib' project get's updated for one child project and not for another, so we can really use our lib-project as a code-package?  
So for example 1 department would still run lib-project V2, while another department would run lib-project V3, so the first department can take their time to test the newer version before it is auto-pushed.

One idea we have is to have 1 dev-lib project, but deploy it to project1-lib and project2-lib project on our production env.

I wonder if anyone has a solid way of tackling this.  
Thanks!

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [October 9, 2023, 2:01pm UTC](https://forum.inductiveautomation.com/t/project-packaging/80202/2 "2023-10-09T14:01:14Z")

</div>

> [@louagejasper](#):
>
> updated for one child project and not for another

No. (You are basically asking for multiple inheritance, which isn't happening anytime soon, if ever.)

The approach I recommend is to override that resource in a dev project, make and thoroughly test the changes, then send it back to the parent project.