The biggest question for me in this multi-version Library approach is how do write the earlier version of a Library Part where the Library Part utilizes a feature that is available only in the latest version.

Two examples:
SkyObject and SunObject appeared in AC10. How do you write this in AC9 so that it works the same way as in AC12?

A Library Part is using a REQUEST function and then is displayed accordingly. Earlier versions of ArchiCAD do not have that REQUEST function. So all code that is based on that REQUEST function simply cannot be implemented in the earlier versions of the Library Part.

So I am thinking about these kinds of scenarios and do not know if there is any solution to that.

Guys, don't get me wrong, I think this is a great idea, I just don't know whether and how it could work.

laszlonagy wrote:
Two examples:
SkyObject and SunObject appeared in AC10. How do you write this in AC9 so that it works the same way as in AC12?

I think what everyone wants is a smooth transition forward, i.e. from old versions of ArchiCAD to new ones. This can become messy when every library part appears to be different because the name has the version number appended, especially if a project is active across multiple versions of ArchiCAD.

Conversely, I can't think why anyone would want to take a project back from AC12 to AC9. And even if you did, wouldn't it be much easier if the AC9 parts had the same name and automatically slotted in where required? They may not do exactly the same thing, but you have to expect loss of functionality if you really want to drag projects back into old versions. The same would be true of any SEOs used.

Perhaps I'm missing something (it wouldn't be the first time ). Can you explain why old objects should provide the same level of functionality as new ones just because they have the same name? Under what circumstances would that matter?

Ralph wrote:
Perhaps I'm missing something (it wouldn't be the first time ). Can you explain why old objects should provide the same level of functionality as new ones just because they have the same name? Under what circumstances would that matter?

Perhaps I am missing something.
Or actually I assumed something which was not actual.

When I read the starting post of the thread I assumed that the main thing or wish about version-free libraries would be to be able to work in AC 13 for example, then save it as AC12 for a colleague who does not have AC13 and he be able to use the AC13 (or perhaps version free) library objects in AC12 without feature loss. I mean, for example, the object in AC12 should look and act and display like in AC 13 because maybe they will save PDFs for the client, not the guy with AC13. Or whatever.
All my comments were related to that scenario.

But as I re-read the thread, this is just a little part of the whole picture. So all my earlier comments should be taken with that modifier.

This is a huge issue for me. I don't do plans that get built, and then move on to a new plan never to go back. I evolve the same plans over years, and years. Smartparts Libraries (as an example) seems to be able to make his libraries evolve. I am still using the same windows and doors I have for years, but they are updated and still work without having to replace the placed object. It has not always been smooth, but never the less, it is working. I started using AC's cabinets (now I consider it a mistake). A buggy cabinet, and there have been quite a few, are not simply fixed, but replaced with the newest version. It's absurd to add lines to make a cabinet read right in elevation. Yes, 13 fixes some of these problems, but that doesn't help all by 12 parts. You have to carry forward many versions of the cabinets and macros or replace the placed object. This is #$%@ ridiculous.

My issue has nothing to do with back saving, but library clutterosity. How many versions of a cabinet do I need to keep in my active library because I open plans that might not have been opened for a few years? Why can't the part be fixed and still work on an AC10 pln, or AC11 pln, AC12 pln etc.

My worry with small independent libraries is that persons continued support and development. We do get old. AC's system is very problematic for me.

Maybe I'm wrong, but the libraries are still regional specific. The main difference is embedding objects that are created for that pln. (like a stair). But, they are regional specific.. still a US version.

I'm not concern with back reading or back saving. I just want parts that are buggy to be fixed in back versions, or better yet, figure out a better way than renaming the same object each version. I don't want "MyAClibrary" having 5 folders of cabinets to go through when the only difference is a bug fix. If it is a unique part, then a new name is appropriate like your great close idea:) Now, how many DW's do I need????? I need exactly one. They tweak the parts, which is great, but a new name *^$%.... If you need to send you library to someone working on a project for you,. or TW, the libraries are way bigger than they need to be IF objects kept the same name.. like SmartParts.

Thanks for the attention to this complex issue.

Hi All,

I'm sorry, I joined the discussion this late. I monitor only the 'Libraries / Library Parts / GDL' section (OK, I try to...).
I have a few comments here.

First, all old library parts can be loaded and used in AC13 (I guess from AC5.0 or so). On top of that they should work just as they did earlier. Naturally, there can be some bugs but we correct them as possible to serve this compatibility goal. (Yes, I know we broke this full compatibility principle on purpose with the UI around AC11. This was a consequence of OS changes.)

Second, backward compatibility is a tough issue. There is no obvious way to accomplish that. (1) Hotfixing old AC-versions to run the newest GDL is a no-go as GDL is in a strong connection with the model generator context. (2) Omitting extra parameters (providing they are coming from a newer version of GDL) would corrupt error detection and usually new parameters aren't and cannot be added at the end. (3) Omitting unknown commands is against the concept of macro calls in GDL.

In general, I agree with Ralph: there should be an easy way migrating forward and this could be a basis for all relevant cooperation.

Side note #1: Library part replacement doesn't consider names from AC12 on - it is based on internal IDs.

Side note #2: A little step toward multi-version libraries was made in AC13. On one hand, saving a v13 project containing an embedded library _is_ converting v13 library parts back to v12 ones. On the other hand, AC has to tell its version to the library parts. 'ac_programVersion' fix named optional parameter was introduced for this.

I wasn't able to give solutions and big good news... I can confirm though that migration is a high priority issue for ArchiCAD development. I hope you'll see some improvement even for v14. Thank you for the feedback - there will be some serious thinking about it at GS HQ.

Regs,
Zsolt