Add safety check when publishing unstable APIs

[rydrman]

This feels a little unnecessary without the additional definition of the new API type, but I'm leaving that part in #598 so that this can be merged separately.

[codecov]

Codecov Report

Attention: 12 lines in your changes are missing coverage. Please review.

Comparison is base (e8cf549) 53.55% compared to head (9c0c829) 53.40%.
Report is 277 commits behind head on main.

❗ Current head 9c0c829 differs from pull request most recent head a6a69cb. Consider uploading reports for the commit a6a69cb to get more accurate results

Files	Patch %	Lines
crates/spk-cli/common/src/publish.rs	18.18%	9 Missing ⚠️
crates/spk-schema/src/spec.rs	66.66%	2 Missing ⚠️
crates/spk-cli/group2/src/cmd_publish.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #630      +/-   ##
==========================================
- Coverage   53.55%   53.40%   -0.16%     
==========================================
  Files         258      257       -1     
  Lines       20466    20352     -114     
==========================================
- Hits        10960    10868      -92     
+ Misses       9506     9484      -22     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jrray]

This help string is likely going to be misunderstood to be something related to package API compatibility / compat values or whatever.

I suggest at least expanding the description to "package spec version" or similar and it would help to briefly touch on what the dangers are for enabling this or at least mention that enabling it might be dangerous.

[rydrman]

Done, let me know what you think. Github is being slow to update so in case it doesn't, I changed it to:

    /// Allow publishing package specs written in unstable api versions
    ///
    /// The api version of a spec is the value of the `api` field within it.
    #[clap(long)]
    allow_unstable_api: bool,

[jrray]

Presumably some future build of spk will have a newer recipe API version flipped to "stable" but that new build may not be in common use yet or fully deployed.

What versions are allowed to be published to a repo could be a property of the repo rather than the spk client. For example, if I configured our production "origin" repo to not accept "v1" packages until we have fully deployed v1-aware builds of spk everywhere and have retired non-v1-aware builds, then I would know that nobody would be able to publish packages to origin (accidentally or otherwise) that might break tools in production.

I'm reminded how simple things like spk ls stopped working when we were in a transition period between python and rust, because ls would crap out the first chance it got if it saw a package it didn't like.

[rydrman]

Our goal, I believe, is still to ignore packages in a repo that are invalid. That being said, I think this is definitely an idea to explore, but if it's the same to you I'd like to start with this as it's a lot less involved. We can then circle back when the v1 is actually being discussed and when we start to re-open conversations on migration

[jrray]

Since we last talked about this, an spk conf file got added. I think it would go a long way to address my concern if we could have this "is_stable" method return something defined the conf file, if present, otherwise it can default to v0.

[rydrman]

The goal of is_stable was specifically for things like v1beta where the version itself is not considered stable by definition. Perhaps we need a separate concept for versions that are considered acceptable to publish that can be configured?

[rydrman]

From the meeting today:

• @rydrman to rebase and ping again
• let's get this in, knowing that we will want to build on it when we get there - likely being able to query some kind of allowlist within the repo itself rather than it being part of the build

[rydrman]

Pinging this again for a review