Hi! Should org.jabref.logic.exporter.MetaDataSerializer#serializeCustomEntryTypes be updated so that custom entry types are always serialized to the v2 format going forward?

Hi! Should org.jabref.logic.exporter.MetaDataSerializer#serializeCustomEntryTypes be updated so that custom entry types are always serialized to the v2 format going forward?

Meta: I miss what you would do :p

You know, I am thinking in MADR, especially using "decision drivers".

Decicion drivers:

• Maintainable solution (code, releases)
• Backward compatibility if possible (some users do not switch JabRef versions - or use two versions in parallel, because newer versions sometimes do not work)

I would vote to always use v2 here - but then include the feature in the next major release (because this breaks compatibility). However, I do not see JabRef 6.0 coming the next weeks.

Thus, use (existing) v1 serialization if single field properties and use v2 if v1 cannot be used. -- For JabRef 7.0 (!) we can remove that logic and always migrate to v2.

Same here! 😄

Thankyou for the pointers!
I think we would have to use v2 in all cases where a custom FieldProperty is specified, even if it is just a single field property?

For example, using the person entry type with Name field having a single field property PERSON_NAMES.
Using v1 we would get: jabref-entrytype: person: req[Name] opt[]

Using v2 would retain the field property info: jabref-entrytype-v2: person: req[Name|PERSON_NAMES] opt[]

I think we would have to use v2 in all cases where a custom FieldProperty is specified, even if it is just a single field property?

I fully agree!

What could work is mixing v1 and v2? Only use v2 for those entry types requiring it and write the others as v1. Thus, not all are "lost" when opening with an old version, but only "some".

Thinking aloud: We should not do, because of too many changes in the bib file: write v1 always and v2 *additionally. The reader then needs to prioritize v2 over v1. We could keep that for version 6.0 and remove that for version 6.1.

Thinking aloud: We should not do, because of too many changes in the bib file: write v1 always and v2 *additionally. The reader then needs to prioritize v2 over v1. We could keep that for version 6.0 and remove that for version 6.1.

yes that sounds good!
we can write both v1 and v2, and the reader can prioritize v2 if present

Hi @koppor, the parser has been updated so that org.jabref.logic.importer.util.MetaDataParser#parseCustomEntryType can parse both v1 and v2 entry types.

Regarding backward compatibility, it looks like even if we write both v1 and v2 it can lead to an incorrect additional entry type when reading using an older version, because the v2 entry type would be parsed incorrectly. Given this, I was wondering if we can write only the v2 version in the Serializer?

Regarding backward compatibility, it looks like even if we write both v1 and v2 it can lead to an incorrect additional entry type when reading using an older version, because the v2 entry type would be parsed incorrectly. Given this, I was wondering if we can write only the v2 version in the Serializer?

Without reading the code, I don't understand. Isn't v2 just ignored in older versions? I thought, unknown meta data keys would be ignored?

Please start to craft an ADR (https://adr.github.io/madr/) to capture pros and cons of each option.

End user requirement: Support of "cited by". See https://discourse.jabref.org/t/wrapping-of-custom-entry-fields/4339.

Thanks! I’ll look into support for that too

Hello @aqurilla, any plans to continue working on this? I think it would be a huge waste to not merge this valuable contribution.

Hi @HoussemNasri, yes I’ll continue on this. Got a bit sidetracked!

@aqurilla May we ping again? ^^

Your pull request conflicts with the target branch.

Please merge with your code. For a step-by-step guide to resolve merge conflicts, see https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line.

@junie-agent Fix the merge conflicts

Junie is failed!

Details: ❌ Failed to fetch fix-for-issue-9840 history. This could be due to:
• Branch "fix-for-issue-9840" does not exist in the repository
• Network connectivity issues
• Insufficient permissions to fetch from the repository
• Git authentication problems
Original error: Failed with exit code 128

View job run

The requested changes were not addressed for 10 days. Please follow-up in the next 10 days or your PR will be automatically closed. You can check the contributing guidelines for hints on the pull request process.