Stablize spec 3.0.0 #772
Stablize spec 3.0.0 #772
Conversation
arithx
left a comment
arithx
left a comment
There was a problem hiding this comment.
Generally LGTM.
Should we just go ahead and drop the deprecated fields from the docs in this PR and then follow up later with the removal of the actual fields?
|
|
||
| package config | ||
|
|
||
| import ( |
There was a problem hiding this comment.
Minor: Should we change the commit title to *: stabilize spec 3.0.0?
Make 3.0.0-experimental into 3.0.0.
Do not hardcode hashes in test configs. Move the servers to their own package (to avoid dependency loops) then export the hashes a variable instead.
Do not hardcode the hashes of fetched configs; instead, use the servers package to get a calculated one.
|
Fixed commit message. I'd rather remove the docs when we remove the fields. They're marked deprecated in the spec too, so I'm not too concerned. |
|
This looks good to me!
OK that makes sense to me. I think we should have FCOS switch back to git master before that so that folks other than you and me can write 3.0.0 configs and test the mount/umount stuff etc... :) |
Absolutely |
|
does this mean, after this lands, we can go ahead and move MCO and other components straight to v3? :) |
jlebon
left a comment
jlebon
left a comment
There was a problem hiding this comment.
Just realized I hadn't given an official GitHub approval on this!
|
|
5 participants
Wellll.... kind of. It's stable enough for other packages to start importing it and using it, just don't use the deprecated fields.
We reserve the right to break the spec until the stable 2.0.0 (Ignition version, not spec version) release, although we do not anticipate any backwards incompatible changes EXCEPT removing deprecated fields.