Content library management and backwards compatibility

[Cory.Killpack]

Our content library is getting unmanageable (we have content from vs. 2009 and on). The dilemma we face as an MEP firm is that the version of Revit used on a project is largely determined by the architect, though we strongly suggest to use the most current. Thus we cannot necessarily abandon, delete, or archive libraries for previous versions because we have multiple clients and they do not all deploy at the same time. And unfortunately we can't afford to lose a job based on it being in an older version of Revit.

That being said, how is everyone managing their Revit family content libraries? Do you just have one library that just gets upgraded with each deploy of Revit? Is it feasible to manage one library and use multiple versions of Revit? Or do you keep "legacy" libraries for each version?

I'm considering consolidating libraries by establishing a family naming convention that contains the year of the version used to create the family. Then possibly locking down the library to be read only so we can't accidentally overwrite an older family with a newer one. And thoughts here?

All suggestions/comments are appreciated.

[Cory.Killpack]

Bump. Anyone have thoughts on this?

[sbrown]

We save each library per Release, IE we have our 2010, 2011 and 2012. We delete the older libraries once every job utilizing that release is over. We will create new content in the older version and upgrade using the batch upgrade utility.

[Cory.Killpack]

Thanks for the info Scott. If I may pry a little further, do you also recreate your project templates with every release? If not, then the families loaded in an upgraded template are still pathed to a previous release library true? How do you work around that?

[geistwolke]

We have content per release years: 2009, 2010, 2011, 2012. These are kept on a 2-3 year cycle (2 if there is a major change, which never happens..) at which point we upgrade to a standard release, which is usually one year prior to the current release. For example we are standard 2011 right now and will continue to create new content to 2011 for a while. There is not much need to upgrade a whole library unless we plan to develop to that libraries version. It takes a split second for someone to insert, for example, a 2011 family in a 2012 project or use the 2011 templates.

[Cory.Killpack]

We have content per release years: 2009, 2010, 2011, 2012. These are kept on a 2-3 year cycle (2 if there is a major change, which never happens..) at which point we upgrade to a standard release, which is usually one year prior to the current release. For example we are standard 2011 right now and will continue to create new content to 2011 for a while. There is not much need to upgrade a whole library unless we plan to develop to that libraries version. It takes a split second for someone to insert, for example, a 2011 family in a 2012 project or use the 2011 templates.
I would agree that a 2 to 3 year cycle could help with the non-backwards compatable issue. If you do that, then what is the purpose of having a library for each release? Perhaps you (we) could keep a 2009, and 2011 library and ditch the others. Then next year create/upgrade a 2013 library. Certainly an interesting thought. Thanks for sharing! I'm still trying to figure this one out!!