Repository navigation
chore: move the in-development version to 0.3.0.dev0 - #691
Conversation
The next release is 0.3.0-incubating, so the in-development version becomes 0.3.0.dev0. There is no 0.2.0 release. - Set 0.3.0.dev0 in the schemas, spec.yaml, the Python package, the specification and ontology documents, the examples, the compliance fixtures and the tests. - Record in the version history that 0.3.0.dev0 replaces 0.2.0.dev0, and that documents declaring 0.2.0.dev0 must declare 0.3.0.dev0. - Reject 0.2.0.dev0 as an embedded model version in the ontology tests. The expression language revision table keeps its dated 0.2.0.dev entry.
christianeu-db
left a comment
christianeu-db
left a comment
There was a problem hiding this comment.
looks good - left a few notes to consider but feel free to address them as followups
|
|
||
| def _doc(metrics=None, datasets=None): | ||
| document = {"version": "0.2.0.dev0", "name": "t"} | ||
| document = {"version": "0.3.0.dev0", "name": "t"} |
There was a problem hiding this comment.
Not a blocker, but no workflow runs anything under compliance/. validation-ci.yml and python-ci.yml do not list it in their paths, and neither runs the grader tests or validates the fixtures. So the green checks on this PR do not cover this file or the nine *.ossie.yaml fixtures. Locally, the 13 grader tests pass and all nine fixtures validate.
This matters more after the rename. #631 adds five more portability fixtures that declare 0.2.0.dev0, and #310 adds an ontology example that no CI step validates. Either one can merge green after this PR and leave a document on main that the schema rejects. Should we add compliance/** to the Validation CI paths, with steps that run the grader tests and validate the fixtures? A follow-up PR is fine too.
| ### Migrating earlier document shapes | ||
|
|
||
| This is a breaking change in the unreleased `0.2.0.dev0` specification. Earlier | ||
| This is a breaking change in the unreleased `0.3.0.dev0` specification. Earlier |
There was a problem hiding this comment.
nit: the break is still in the 0.2.0.dev0 snapshot. 0.3.0.dev0 should always have the flattening applied.
(non-blocking side note: perhaps these kinds of migration notes should in a separate file rather than the core -spec. the core spec just states the current state w/o reflecting on the past)
|
@jbonofre do you mind updating core-spec/wide_table_semantics.md. This could also be a followup PR (if so, I can take it) |
apache/ossie#691 renamed the in-development version of the schema; there will be no 0.2.0 release. The vendored apache-ossie moves to d700cde, and the TPC-DS fixture is again an exact copy of the example on Ossie's main. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
apache/ossie#691 renamed the in-development version of the schema; there will be no 0.2.0 release. The vendored apache-ossie moves to d700cde, and the TPC-DS fixture is again an exact copy of the example on Ossie's main. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
…filter Resolved the sole conflict in core-spec/spec.md Version History by keeping apache#691's 0.3.0.dev0 heading and replacement note, and re-applying apache#704's Dataset.source table-identifier changelog bullet. Bumped examples/dataset_sources.yaml from 0.2.0.dev0 to 0.3.0.dev0 to match main.
apache/ossie#691 moved the spec's version to 0.3.0.dev0; there will be no 0.2.0. dactopus-ossie-clickhouse 0.15.0 and newer read only the new version, so CI moves its pin from 0.14.0 to 0.16.0, and AGENTS.md drops the old name custom_extensions it kept until the pin moved. Nothing else in the models changes. The DuckDB extension (0.3.0) reads the new version and answers as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PR #691 moved the in-development version to 0.3.0.dev0 everywhere the version is declared, but the Layer 3 "Wide Table Query Interface" spec (core-spec/wide_table_semantics.md) kept its draft-spec badge at 0.2.0.dev0. Its Layer 2 sibling (relational_semantics.md) was bumped in that PR, so this straggler left the layered spec set inconsistent. Bump the badge to 0.3.0.dev0 to match. Co-authored-by: Isaac <no-reply@databricks.com>
Summary
The next release is
0.3.0-incubating, so the in-development version becomes0.3.0.dev0. There will be no 0.2.0 release.0.3.0.dev0everywhere the current version is declared. That coversossie-schema.json,ontology.json,mapping.json,spec.yaml, the Python package (pyproject.toml,uv.lock,models.py),spec.md,ontology.md,relational_semantics.md,docs/index.md, the examples, the compliance fixtures and the tests.const, so documents that declare0.2.0.dev0no longer validate. The version history inspec.mdsays they must declare0.3.0.dev0, and the ontology tests now reject0.2.0.dev0. Because it changes the schemas, this counts as a specification change, which needs three binding +1 votes.apache/ossie-convertersneeds a matching change. It writes0.2.0.dev0in about 30 files.0.2.0.deventry.