Change how we do CKAN metadata versioning.

[pjf]

Right now we have a mandatory spec_version field, which is always 1. It has never been updated, and I don't think it's really fulfilling its intended purpose.

I think we should change this to specify the minimum version of the ckan.dll required for the file to operate correctly. This means that:

• We can push new files to CKAN-meta without worrying about old clients.
• We can push metadata before the code for it has been written, which is useful if the spec has been updated but the code has not.
• We can have our validators ignore any files which are written for a future spec.

Clients should ignore metadata for versions higher than themselves. Dev clients may (and probably will) accept future versions, which means we can do testing.

The downside is that we're now targeting a version of code rather than a version of the spec. However the code and the spec live in the same repository and share the same tags, so I don't imagine this will be a problem for some time. In most cases, we want to encourage people to write documents for the minimum ckan.dll version that will support them. (On release, we'll encourage everyone to target 1.0)

[Wizarth]

Do we have the ability to do side by side versions of the dll? Probably not
worth the effort though, of trying to support old spec definitions.

Idea put on table, dismissed.
On 01/11/2014 5:28 PM, "Paul Fenwick" notifications@github.com wrote:

Right now we have a mandatory spec_version field, which is always 1. It
has never been updated, and I don't think it's really fulfilling its
intended purpose.

I think we should change this to specify the minimum version of the
ckan.dll required for the file to operate correctly. This means that:

• We can push new files to CKAN-meta without worrying about old
  clients.
• We can push metadata before the code for it has been written, which
  is useful if the spec has been updated but the code has not.
• We can have our validators ignore any files which are written for
  a future spec.

Clients should ignore metadata for versions higher than themselves. Dev
clients may (and probably will) accept future versions, which means we
can do testing.

The downside is that we're now targeting a version of code rather than a
version of the spec. However the code and the spec live in the same
repository and share the same tags, so I don't imagine this will be a
problem for some time. In most cases, we want to encourage people to write
documents for the minimum ckan.dll version that will support them. (On
release, we'll encourage everyone to target 1.0)

—
Reply to this email directly or view it on GitHub
#229.

[pjf]

We don't have the ability to do side-by-side copies. However if you're running v1.12, that should be able to read v1.02 files just fine. This is mainly intended so we can extend the spec sensibly, with things like #11, #223, etc.