roll
roll
Hi @pdelboca @pierrecamilleri can you please take a look?
DONE in https://github.com/frictionlessdata/datapackage/pull/68
Hi @zaneselvans, I'm ccying @pierrecamilleri
Hi @pierrecamilleri, yes it's been moved to the Open Data Editor codebase
I would love to see more readable documentation 👍 Currenlty, I'm working on a project on top of `nodejs-polars` and, honestly, I just use Github code as a documentation because...
I think it's a valid point, and as a Working Group, we can vote on the version when we have finished the changelog. Peter outlined the pros of staying on...
@peterdesmet I think we need to work with core standard and domain-specific extensions as projects so it will be `core vX`, `camtrap vY`, `fiscal vZ` etc. So I would just...
@peterdesmet Answering https://github.com/frictionlessdata/datapackage/pull/12#issuecomment-1881247519 as I think it will be good to have everything related to the versioning discussion in one place. > Why is it structurally non-breaking for implementations? By...
Also, it's the specifics of working on standards that many kinds of new features (a property added) don't have full `forward-compat` as e.g. a new constraint will kind of break...
I think on the Standard side, we need to decide whether we provide standard version information for an individual descriptor e.g. as proposed here https://github.com/frictionlessdata/specs/issues/444 I think every implementation is...