backwards compatibility?

[Vince D Calhoun]

Hi all,

          Hope everyone is well! I may have missed this, but just wondering what attention there is to backwards compatibility as BIDS continues to be developed? In particular, for those of us trying to build BIDS into production level systems, the rapid version updates are not something that we can keep up with (e.g. differences between 1.5 & 1.6 are huge and the releases are coming really fast…which is good, but also challenging as new requirements are added which may overlap with previously unspecified formatting). So the only way to make any progress is to freeze using an old version of BIDS until some point when we can devote resources to upgrading (which is a major task to upgrade 10’s of TBs of data).  Are there any plans to try to build in more backwards compatibility considerations?

 

Best,

 

Vince

[Chris Markiewicz]

Hi Vince,

Backwards compatibility is a significant consideration in all updates to BIDS, and I believe all BIDS 1.5.0 datasets remain valid BIDS 1.6.0 datasets. The vast majority of the changes are additions of supported data, rather than new requirements on existing data. One thing that may be generating the appearance of new requirements is improvements to the validator allowing us to enforce previously unenforced requirements.

We have introduced the "DEPRECATED" keyword, which we use in a small number of cases, that has the meaning that the metadata/name is still valid, but there is a new recommended alternative that we anticipate will fully replace the old form in BIDS 2.0, when backwards compatibility will be broken. While this may produce warnings, if it's causing validation failures, that would be a bug.

Do you have any specific issues that have come up? If we're failing to maintain backwards compatibility, that is something we should correct in our review process.

Best,

Chris

--
We are all colleagues working together to shape brain imaging for tomorrow, please be respectful, gracious, and patient with your fellow group members.
---
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/BLAPR05MB7313A6CD196A4658012CD4BEC53C9%40BLAPR05MB7313.namprd05.prod.outlook.com.

[H. Jeremy Bockholt]

Hi Chris and others,

Thanks for the response.

Is there a timeline for BIDS 2.0 dev release?

I think it would be important for our team to see/contribute to that soon as it is, as we will likely have 1.5Pb of formatted BIDS in the next few months.

We also already have a good mixture of 1.4, 1.5, and now trying to establish our 1.6 BIDS data.

I think our main concern is just not wanting to update already existing BIDS data to a newer version, especially for longitudinal studies.

Have we thought about versioning a given BIDS collection, such that the collection itself is able to track the history, changes to the data set, possibly even able to 'rewind' to a certain tag/date.

I would naively just use GIT for this, but if there's already an approach or something in the works for this, that would be great.

Another feature, and we will likely write something for this or maybe just extend pyBIDS, but a self-update type of functionality would be nice.

go into a collection, self-update, if the dataset is valid and any missing metadata is available in the relevant JSON or rawdata, the new metadata is provided, legacy or DEPRECATED data is set accordingly, and the dataset is updated.

thanks for the discussion, happy to weigh-in further if this is helpful to the future development and to other users,

jeremy

To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/CAJqDEcG%2B%3D7YgNyZtJohtPhXw%2B0uc052tPxCSMWj3f1cjGw86oQ%40mail.gmail.com.

[Chris Markiewicz]

Hi Jeremy,

> Is there a timeline for BIDS 2.0 dev release?

> I think it would be important for our team to see/contribute to that soon as it is, as we will likely have 1.5Pb of formatted BIDS in the next few months.

Not at present. It's more of a concrete term for the backwards-incompatible future, but as far as I'm aware, nobody is making an active effort to draft it.

> We also already have a good mixture of 1.4, 1.5, and now trying to establish our 1.6 BIDS data.
> I think our main concern is just not wanting to update already existing BIDS data to a newer version, especially for longitudinal studies.

I think this makes sense. I see "BIDSVersion" as a way of indicating the age of the dataset, but it does not seem important to me to ensure that all datasets are consistently upgraded to the latest version. It is also useful for, say, PET tools, which might require BIDS-1.6+, since that's when PET was standardized.

> Have we thought about versioning a given BIDS collection, such that the collection itself is able to track the history, changes to the data set, possibly even able to 'rewind' to a certain tag/date.
> I would naively just use GIT for this, but if there's already an approach or something in the works for this, that would be great.

Have you looked into DataLad (https://handbook.datalad.org/)? It is exactly git for data, and uses a technology called git-annex to keep the repository from becoming useless with all the large files.

> Another feature, and we will likely write something for this or maybe just extend pyBIDS, but a self-update type of functionality would be nice.

> go into a collection, self-update, if the dataset is valid and any missing metadata is available in the relevant JSON or rawdata, the new metadata is provided, legacy or DEPRECATED data is set accordingly, and the dataset is updated.

Agreed! I started on something similar a while back, to help upgrade derivatives from pre-release to post-release state: https://github.com/bids-standard/pybids/pull/654

It would be good to finish that up and generalize to tasks like those you've mentioned.

Best,

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/CAA1oEYNEM999tKuTr%3DQ89SWPkc%2BZ9J7KuUH%2BpJZHP4gO%2BfJzgg%40mail.gmail.com.

[Robert Oostenveld]

Hi Jeremy

BIDS uses semantic versioning, which is explained here https://semver.org. After 1.0 came out, the only thing that has happened so far are “MINOR" version increments (the y in x.y.z), i.e. when functionality was added in a backwards compatible manner. 

If you have a certain version of BIDS that meets your needs (like 1.4 or 1.5), I recommend to stick to it and not upgrade "just because" there is a new version. A good reason to upgrade the representation of new (or even existing) data would be when that version has added value for you.

The https://bids-specification.readthedocs.io/en/stable/ website will by default show the latest version. But in the lower right corner you can switch to the documentation of older versions. And on zenodo we keep all versions as PDFs. 

best

Robert

To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/CAA1oEYNEM999tKuTr%3DQ89SWPkc%2BZ9J7KuUH%2BpJZHP4gO%2BfJzgg%40mail.gmail.com.