REL: v1.5.0

[franklin-feingold]

PR marks the start of our 1-week freeze period to prepare to release a new version of the standard (please refer to our release protocol)

This release will officially extend BIDS to support ASL and qMRI imaging

[sappelhoff]

cc @HenkMutsaerts @patsycle @Gilles86 @agahkarakuzu

[patsycle]

Can we still do minor changes in BEP005 during this freeze period? If yes, what is our deadline?

[sappelhoff]

Can we still do minor changes in BEP005 during this freeze period? If yes, what is our deadline?

if by "minor changes" you mean bug fixes, then these are still allowed until the release. New features will have to wait for the next release and must then be backwards compatible.

[marcelzwiers]

I don't know if it is not too late for this, but I would like to propose to rename the entity key in the entities.yaml file (as mentioned also here: #720 (comment)). Because now we have e.g.

inversion:
  name: Inversion Time
  entity: inv
  description: |
    [..]

Which is somewhat strange / confusing because inv is not an entity but just the entity key. Could we change this to:

inversion:
  name: Inversion Time
  key: inv
  description: |
    [..]

In that way getting data from the entities.yaml file is also much cleaner. Instead of the strange looking

entities["inversion"]["entity"] == "inv"

we can then do the much nicer

entities["inversion"]["key"] == "inv"

[patsycle]

Hi @sappelhoff @franklin-feingold When is the deadline for the release? We are still discussing the requirement level of 1 ASL field, and would have a short TCON within our group on Friday. But would we still be in time to have this included in the current release?

[sappelhoff]

When is the deadline for the release? We are still discussing the requirement level of 1 ASL field, and would have a short TCON within our group on Friday. But would we still be in time to have this included in the current release?

The release is planned for today, what is the exact issue?

[patsycle]

for

TotalAcquiredVolumes is now optional but recommended in some cases. However, it appears to be more important for analysis than expected (based @HenkMutsaerts tests), so it should be come requried and a slight change in name an definition. This also implies some small changes in validator.

[sappelhoff]

I think you could turn it to required now, prior to the release (today), and then do fine-tuning for the next release. But I have also asked the other maintainers about their opinion.

Until we know an answer, it'd be helpful if you could prepare a complete PR so that we see the scope and can then (potentially!) hit the merge button before a release.

But requirement levels are usually something that should be well thought through, as these are hard to change in the future with regards to backwards compatibility.

[sappelhoff]

I don't know if it is not too late for this, but I would like to propose to rename the entity key in the entities.yaml file (as mentioned also here: #720 (comment)). Because now we have e.g.

@marcelzwiers thanks for the input. Just to put your mind at ease --> the schema is under heavy development and will continue to stay in flux. The forthcoming release will not prevent us from potentially making the adjustments you suggest, because the schema is currently just representing the specification, that is it's (currently) not the specification itself. So we don't have backward compatibility issues yet.

[patsycle]

I think you could turn it to required now, prior to the release (today), and then do fine-tuning for the next release. But I have also asked the other maintainers about their opinion.

Until we know an answer, it'd be helpful if you could prepare a complete PR so that we see the scope and can then (potentially!) hit the merge button before a release.

But requirement levels are usually something that should be well thought through, as these are hard to change in the future with regards to backwards compatibility.

I'll do these changes today! keep you posted

[HenkMutsaerts]

Dear Stefan, Apologies for my belated answer; in our last tests with 50 ASL flavors, there is one parameter for which we would like to slightly change the requirement level, name, and description; like Patricia stated. This will - albeit very slightly only - affect the BIDS examples, BIDS validator, and BIDS specification. Can we still put this in BIDS 1.5.0 or should this wait for 1.5.1? Many thanks, apologies for any confusion, Best wishes, Henk Best wishes/hartelijke groet, *Henk(-Jan) Mutsaerts, MD PhD* Amsterdam UMC/ UZ Ghent Phone: +31 6 4390 8284; Skype: hj.mutsaerts

…

On Tue, Feb 23, 2021 at 11:31 AM Patricia Clement ***@***.***> wrote: I think you could turn it to *required* now, prior to the release (today), and then do fine-tuning for the next release. But I have also asked the other maintainers about their opinion. Until we know an answer, it'd be helpful if you could prepare a complete PR so that we see the scope and can then (potentially!) hit the merge button before a release. But requirement levels are usually something that should be well thought through, as these are hard to change in the future with regards to backwards compatibility. I'll do these changes today! keep you posted — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#736 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGT42LSNHEEIS6YMDG6XFKTTAN7ZNANCNFSM4XXOS33A> .

[patsycle]

I think you could turn it to required now, prior to the release (today), and then do fine-tuning for the next release. But I have also asked the other maintainers about their opinion.

Until we know an answer, it'd be helpful if you could prepare a complete PR so that we see the scope and can then (potentially!) hit the merge button before a release.

But requirement levels are usually something that should be well thought through, as these are hard to change in the future with regards to backwards compatibility.

Did the changes in BEP005 but stuck on the PR part now..

[effigies]

I think you could turn it to required now, prior to the release (today), and then do fine-tuning for the next release. But I have also asked the other maintainers about their opinion.
Until we know an answer, it'd be helpful if you could prepare a complete PR so that we see the scope and can then (potentially!) hit the merge button before a release.
But requirement levels are usually something that should be well thought through, as these are hard to change in the future with regards to backwards compatibility.

Did the changes in BEP005 but stuck on the PR part now..

Created: #742

Assuming that's what you were stuck on...