Stable version numbering (ie 1.x.x)

[charles-turner-1]

I think we're probably at a point where we don't want to be altering the behaviour of the catalog in a way that will confuse users and/or change workflows substantially.

To reflect this, should we consider updating our version number to a 1.x.x release to indicate that the library interface should be stable?

[marc-white]

I agree we're just about there, but I think there are a few things we need to get lined up before pulling that trigger. In particular:

• [ ] Decide what to do about datasets that may be missing a model value (#223)

• [ ] Confirm the Intake Take2 support/compatibility/upgrade (#153)

• [x] Finalize the catalog version numbering (#191 )

• [x] Get metadata-validate to give a full report, not just the first failure (#216)

• [x] Support for Intake Take2 #233 &

• // Deferred [ ] Work out the frequency dates bug (#188) Any others?

[charles-turner-1]

I think that would be a good target in terms of features. I think we could potentially also think about adding translators for the datasets with open data requests (as of today) - this process is generally pretty straightforward & fast.

• [ ] #202
• [ ] #108
• [ ] #204
• [ ] #175
• [ ] Check path consistency in metadata (/g/data/xp65/admin/intake vs /g/data/xp65/admin/access-nri-intake-catalog).
• [x] #214
• [x] #198
• [x] #197
• [x] #196

[rbeucher]

I agree. Let's do that and we can make a stable release.

[charles-turner-1]

I've edited the features list to add a two parter for Take2 - I'm going to leave #153 open until we've got an E2E build test on a catalog subset.

[charles-turner-1]

@rbeucher @marc-white Did we decide last week to leave #188 out of this release?

[rbeucher]

Yes, pb for later :-)