RE: Part versioning
2025-09-06, 23:30 (This post was last modified: 2025-09-06, 23:31 by Chris Böhnke.)
2025-09-06, 23:30 (This post was last modified: 2025-09-06, 23:31 by 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.
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.