SQL 2012 SSIS Single Package Deployment

Question

I have the following scenario:
I have a 2012 SSIS project that contains two packages and on the release of the project, I deploy the entire project solution which has both packages. I then create a SQL Agent job that executes the packages from the SSIS catalog and all is well.
Down the road, a change is required for both packages and both packages are being developed. The first package change is ready to be deployed and the business wants the change to be implemented and does not want to wait for the second package development.
How do I deploy my project to get the first package deployed without overwriting the second package? I do not want to drop out the second package from the project because the agent job is depending on the package to be located in the catalog. However, I
cannot just create a new project deployment with the second package changes since the second package is not ready to be deployed yet.
Is this possible? In the deployment wizard, nothing is available to select only a specific package to update.
I want to take advantage of the SSIS catalog for configuring connections, parameters and the like but this ability to replace a single package needs to be available.
Can we do something in Powershell to add the updated package to the packages collection, which will overwrite the existing package or would that mess up the project deployment and the OOTB versioning that exists?
Or, is the workaround to create a new project with the Package One Updates and the original Package Two, walk through the deployment wizard to create the ISPAC file and then deploy that project to the catalog. (I guess answering my own question here but
really hoping for something more elegant)
Thanks in advance
Chuck 

Answer 1

I agree completely with Mahesh.
Ever since the days of UNIX makefiles, only those parts of a project which have changed have been recompiled. 
Indeed for instance, Visual Studio does this by default when building .NET projects, C++ etc - only what has changed is rebuilt, I mean it makes sense. Why waste time rebuilding something that hasn't changed at all. 
I do not understand why an SSIS project requires the full redeployment of every single package when only one may have changed - it seems incredibly risky and exposes us to inadvertently deploying changes in other packages that we don't want to. 
The workarounds described above that involve branching/merging etc in order to only be able to deploy a portion of a SSIS project may work to reduce that risk - but they can hardly be called 'best practice'. We risk end up making a mess of our version histories. 
It would be good to get some direction from Microsoft on why it has been implemented the way it has, perhaps there is something we don't understand - in particular the decision to compile all packages into a single .ispac - after all, that's the source of
our problem here. 
It would be handy to have a smaller target unit of compilation - again, forgive my possible lack of understanding here, but what is the reason for the granularity of deployment to be at the project level, and why wasn't the target of deployment simply kept
at the package level?
That was the massive change from 2008R2..
Thanks! Josh