Part versioning

[Peter Blomberg]

Currently, part versioning is done by appending the part number with a letter. The same letters are also used when two designs have the same part number and when a bag contains multiple independent parts. This makes it impossible to automatically determine correct matches to e.g. external resources.

Having the links to external resources as separate meta is useful in particular when the external resources use different numbers or extensions. However, this doesn't solve the whole issue.

Can we begin using v2, v3, etc instead of b, c, d for cases when a "b/c/d replacement file" is created? This would enable all incorrect old versions of the part be available for backward compatibility, but allow new corrections to be distinguished from other uses.

[Philippe Hurbain]

There's another (worse) instance where this a,b c... suffix occurs: when a wrong number was assigned to a part (official), and later on another unrelated part is produced with the same number.

[Orion Pobursky]

This is definitely a place where we can improve. I'd like to see where the discussion goes before I weigh in.

[Chris Böhnke]

Do you intend the versioning for the actual file or merely for it's library entry?
I tend to agree the current solution is not optimal, but there are a few concerns:

1) If the main goal of this is to automatically match to external references, I don't think this will work no matter what you change. Bricklink for example still uses a lot of old Lugnet/Peeron era 3-digit or x-numbers IDs for parts where the official one is known (not to mention them recently breaking old numbering schemes frequently). BrickOwl uses arbitrary numbers anyways. I guess Rebrickable is a bit more consistent, but I'm still sceptical there wouldn't be a hidden issue somewehere.
Matching to Lego's official ones doesn't work always as well, best example is part 2578.

2) What would be the actual naming convention? Keep in mind that backwards compatibility is the big issue here. The "correct numbers" for some parts are blocked and will likely stay blocked.  If an old model contains an obsolete file, you can not change that file. Also already official "part_b.dat" files can not be renamed for the same reason. Changing it only for the future ones but still having (quite a lot) cases without verX as suffix feels a bit pointless to me.

3) Mold changes and Obsoletes aren't the only case for this, but also stickers/sprues/multi-bags. If the system gets changed, that might cause a lot of work.

[Peter Blomberg]

Do you intend the versioning for the actual file or merely for it's library entry?

The library entry, i.e. "Name".

Being relatively new to LDraw, I'm astonished that the 'same' suffices are used for so many purposes. My only concern is to remove bdc replacement files from the abc swamp. If we manage to do it, then every abc suffix will have a real meaning. Obsoletes are already uniquely identified by a "~" in the start of the description.

One of the key arguments for not to correct orientation or point of origin is the abc suffix. Thus, there are many parts in the library where these could be adjusted to follow the rules.

As a second example, I give 31213bp01.dat. Here, the "b" in the name is meaningless and frankly speaking unnecessary. The "b" originates from rotation of the base part, while the "p01" comes from the pattern. Such a "b" would be needed in the name only if the pattern existed for the previous orientation. Now, consider 31213p01b or 31213p01. The latter could be used if it was the first version of its kind (v1 being suppressed). If a previous version had existed, then it would be 31213p01v2.

2) What would be the actual naming convention?

Henceforth, whenever a "b replacement file" is created, it is to be named with v2, v3, v4, etc. Previous letters denoting "b replacement files" should be counted in the numbering. For example, if 12345 is replaced, the new Name would be 12345v2 (comparable to 12345b earlier) and if 12345b is replaced, its new Name would be 12345v3 (comparable to 12345c earlier). If the "b" originated from other sources than replacement, then it needs to be kept; 12345bv2.

I don't even know what would happen currently if an abc item other than b-replacement needs to have its origin fixed - would just a random letter be chosen or would it become two letters.

If we wanted to, we could have a script convert all b-files with a history comment containing "created b replacement file" to follow the new convention, but that would add a lot of obsoleted files to the library for no good reason. Therefore, I'd just follow the new convention for new files, knowing that some day, sooner than with earlier conventions, all of the library will follow the rules.