Great Idea!

So can we agree that instead of an LVLIB it would be preferable to use an LVPROJ file as the source? I'm thinking this makes more sense. You can always put an LVLIB inside of an LVPROJ, which you should be doing anyway.

Steen. In VIPM 2014, you can now have multiple build specs per same source folder. So this could make it easier for you. Combined with the VIPM API, it can do what you need. However, still don't have the "Remove block diagram" option. However, this will be coming soon after VIPM 2014 release as a VIPM Labs build. Stay tuned. is a great idea! (edit by Jim Kring on 3/9/2015)

Since you guys have the code already, can I have it? :)

There are many things that can go wrong with Save As. It's not clean cut. Solving this problem on the package install side would be very difficult. Even on the development side. You need to do testing to make sure the new source actually works. If the down-save from VIPM fails even once, then nobody would use it. It won't be trusted and that's wasted development.

Are you spending a lot of time saving for previous? Then perhaps you should just develop in that version. I think right now, it's common to develop in LV2009. That's a recommended starting point for most tools. If your tool has some special LabVIEW version specific features then it can't be down-saved anyway.

This is a fair request. It's just impossible to get it working to the point which people would actually use it. Besides, some forethought in developing the tool and some education on the customer's side to upgrade LabVIEW doesn't hurt.

This could possibly be implemented by saving a VI as Chris mentioned into the vipb file. One VI for each palette category icon.

Perhaps we should call it "Repair"?

Since VIPCs can now be installed on any LabVIEW version. Is this still a requirement?

Another thought to this. If you were allowed to use a LabVIEW project file to define your build VIs, would this be a better approach? You would just not include files in the project file that you don't want to package.