Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add version to meta.yaml #34

Merged
merged 2 commits into from
Oct 4, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 26 additions & 2 deletions doc/adr/0002-use-meta-yaml-to-track-feedstock-metadata.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,13 +31,37 @@ The format and contents of this file are specified as follows.
### Top Level Data

```yaml
id: noaa-oisst # top-level ID for the feedstock. must be unique and must match feedstock repo name
id: noaa-oisst
version: "1.0"
title: "NOAA Optimum Interpolated SST"
description: "Analysis-ready Zarr datasets derived from NOAA OISST NetCDF"
pangeo_forge_recipes_version: "0.1"
pangeo_forge_metadata_spec_version: "1"
pangeo_forge_metadata_spec_version: "2"
```

| name | description | valid characters |
| -- | -- | -- |
| id | top-level ID for the feedstock. must be unique and must match feedstock repo name | lower case ascii alpha-numeric, no spaces, only dashes allowed |
| version | feedstock version | `{MAJOR}.{̨MINOR}` |
| description | - | Unicode |

#### Version

We use a two-element version of semantic versioning: `MAJOR.MINOR`.
The recipe version starts at 1.0.
Updates to the minor version number are considered minor changes;
when a new minor version is released, bakeries will _overwrite the previous minor version_ of the feedstock's datasets.
Instead, the bakery should _always retain the latest major version_.
Updates that involve concatenation of new elements (e.g. extend the temporal range) are considered minor version updates.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This wording is confusing - didn't you just say that this would overwrite the dataset?

Similarly, retaining the major version: you mean that the latest minor version of each major version will be retained? i.e., that if 3.7 was followed by a 4.x series, then 3.7 will be kept for good, archival?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

didn't you just say that this would overwrite the dataset?

Yes I see how that is confusing. What I mean is that 3.6 ➡️ 3.7 will make 3.6 go away. We won't keep a separate copy of 3.6 around, since 3.7 supersedes it. But this may mean just renaming 3.6 to 3.7 and then appending to it. So I agree that "overwrite" is not necessarily the right word here.

if 3.7 was followed by a 4.x series, then 3.7 will be kept for good, archival?

Correct.

Changes are _minor_ if they will be backwards-compatible with user code which relies on the previous version of the dataset. Changes are _major_ if they have the potential to break existing user code. The following table provides examples for each category:

| Change | Minor | Major |
| -------- | ----- | ------ |
| Updating metadata (e.g. to correct units, descriptions, etc.) | :ballot_box_with_check: | |
| Adding new variables or timesteps | :ballot_box_with_check: | |
| Changing existing variable names | | :ballot_box_with_check: |
| Changing preprocessing functions (that alter existing data) | | :ballot_box_with_check: |

rabernat marked this conversation as resolved.
Show resolved Hide resolved
### `recipes` section

The `recipes` section explains what recipes are contained in the repo.
Expand Down