opencontainers
Update 1.0 branch for 1.0.3 release
This is a cherry-pick of commits from the v1.0.1 release to just before we merged in the working group results, and a few additional Go and CI fixes after that. The v1.0.1 release was picked because there were changes during the past 5 years that were not included in the v1.0.2 security fix.
The following should be on the list of PR's included in this update:
decdb1500673e7ef4fd912e0741f67a49e35d502 Merge pull request #951 from sudo-bmitch/pr-go-1.17 d2cc46db009a50a4677d4b287c882e5f68946a61 Merge pull request #944 from austinvazquez/remove-ioutil-dep 50b6194995ebfd16d933ce16064898d6b7f60249 Merge pull request #941 from sudo-bmitch/pr-spec-components ff0257194e20f7fd17ca21c67a2e725f21c4d4f2 Merge pull request #934 from oci-playground/pr d265d74f4fad249d39fe092122f53c7998afbfe9 Merge pull request #897 from vbatts/another_adopter c27355a1c248f8a1d5971d354ae8ace3a6e795b3 Merge pull request #932 from sudo-bmitch/pr-implementation-regclient f3096cf36396f9201c6ff730c77a8f9ce97390ac Merge pull request #911 from jdolitsky/sajay 20147710b9f272258709b92963550ce093e5c9bc Merge pull request #909 from jdolitsky/brandon 6ad7100eb087e43398e9ea8fe44fffc1501b8984 Merge pull request #919 from nishakm/912-maintainer-template 7b36cea86235157d78528944cb94c3323ee0905c Merge pull request #917 from sudo-bmitch/pr-gha-lint 868548600fee7e58654b2f71f8f5b30557eb29ca Merge pull request #915 from sudo-bmitch/pr-https 37d82a265892e0efe5deac1bc462bce5efd00b34 Merge pull request #910 from jdolitsky/old-maintainers 02efb9a75ee11e05937b535cc5f228f9343ab2f5 Merge pull request #900 from michaelb990/main 8205360b72afd0613e3823bbf978117f78274bd1 Merge pull request #885 from stevvooe/use-embed 9716dee6767f0eaaca3740b1dcb734104e3aa882 Merge pull request #898 from sudo-bmitch/pr-broken-link bac4452888988085f263a61379c521abfd3472cf Merge pull request #826 from jonjohnsonjr/data 1f308fd27264a52f6a089202b1ff9dc15ff27398 Merge pull request #896 from vbatts/implementations ea0209f50ae1a3707cff054cdb6b7487050487de Merge pull request #887 from sanshirookazaki/fix-readme eacdcc10569b68a90558220b29d115363a26790c Merge pull request #871 from wyckster/patch-2 a9fdc379302f4827183c84e368e79bdfe0225803 Merge pull request #884 from vbatts/fix_lint a5463b7f9c8451553af3adcba2cab538469df00c Merge pull request #883 from vbatts/carry_810 679348323e1d2e9d9a84191bf5ffdc0a49576739 Merge pull request #882 from bloodorangeio/why-u-pull-quay b52c1724c3ceb54799d47952c855d508b9e967cd Merge pull request #879 from opencontainers/lint-fixes c5a74bcca799bef045e7fbe74e1b75580fd18d4c Merge pull request #878 from opencontainers/v1.0 43a7dee1ec31e0ad091d2dc93f6ada1392fba587 Merge pull request #869 from SteveLasker/add-acr 9a7a9876500e4de43a25acde2543a4267d9a31dc Merge pull request #875 from SteveLasker/docker-distribution 54a822e528b91c8db63b873ad56daf200a2e5e61 Merge pull request #873 from jpetazzo/fix-config-example 5ad6f50d628370b78a4a8df8a041ae89a6f0dedc Merge pull request #817 from AkihiroSuda/docker-oci-diff 8e42a01fb1b7aa6f9983d5f987bcd17873f15f2e Merge pull request #822 from imjasonh/patch-1 fe0a24978a6629f4b7159928e538dda36c7cec8e Merge pull request #809 from cpuguy83/image-platform 91bc345d66e1647a5f38cb388ce5d122ba3fe436 Merge pull request #863 from vbatts/rm-pullapprove 5ced465cc63831baf25330431a428a9d9444e192 Merge pull request #856 from vsoch/patch-1 d9aa673866f5eaaf54cd036e4ea06fef305d39a2 Merge pull request #793 from vsoch/fix/descriptor-branch-comments fe7b3949255430200eac96950e54cba088bfcb44 Merge pull request #824 from AidanDelaney/patch-1 93e69bcb362ae54a5fe8e0398da3294f890dccb4 Merge pull request #800 from zhsj/remove-go4 083f635f2b04f7f340685a1e0c4393a0feec3679 Merge pull request #860 from lucianoqueiroz/add-background-to-png-imgs 85c28d797bcf49c7aa5e3b45626df5a217dbc2d7 Merge pull request #858 from vbatts/codeowners f18daf27c37a3e5e5f79e0d17ebcc051d8a34775 Merge pull request #855 from jonjohnsonjr/typo 81270cdee5c47c0f05168e5521830787d71aa50d Merge pull request #813 from Iduoad/master 8d2a44c9c39fb1c749ed51915aa80ce2416e178b Merge pull request #846 from vbatts/oci-container 32e130c75417b86fb31aa7b5e57b928442e46cf0 Merge pull request #848 from vsoch/add/github-workflows daf51542d53813621913dde9bf438bd9c1fe32c8 Merge pull request #849 from jonboulle/master 269c1c5e1dca62a25c5fa94929776d758f5373ab Merge pull request #832 from ImJasonH/patch-2 859973e32ccae7b7fc76b40b762c9fff6e912f9e Merge pull request #814 from vbatts/change_image 775207bd45b6cb8153ce218cc59351799217451f Merge pull request #790 from vrothberg/add-zstd-constants 9f4348abedbe4415e6db1f08689fa7588045d982 Merge pull request #788 from giuseppe/zstd d1109113f99146dcabbc1882f8838415971b48c8 Merge pull request #786 from estesp/meeting-ref 6943c5f4c9d29193b36596127c1efb02350b1fcc Merge pull request #757 from unasuke/fix_typo ae1010f0bb27658e9f040391c7b20bb8aa4237aa Merge pull request #782 from odinuge/lint-issue da296dcb1e473a9b4e2d148941d7faa9ac8fea3f Merge pull request #772 from woernfl/patch-1 243ea084a44451d27322fed02b682d99e2af3ba9 Merge pull request #759 from jzelinskie/loosen-mediatypes 09950c5fb1bb6745e72aa26ecde0d540e35f5286 Merge pull request #753 from HaraldNordgren/go_versions b6e51fa50549ee0bd5188494912a7f4c382cb0d4 Merge pull request #740 from francescomari/fix-link e562b04403929d582d449ae5386ff79dd7961a11 Merge pull request #716 from AkihiroSuda/index-is-required 149252121d044fddff670adcdc67f33148e16226 Merge pull request #739 from mtrmac/id-based-loader 577479e4dc273d3779f00c223c7e0dba4cd6b8b0 Merge pull request #736 from AkihiroSuda/bump-up 89b51c794e9113108a2914e38e66c826a649f2b5 Merge pull request #728 from q384566678/add-ln
Note the DCO issue will need to be ignored because it exists in our main branch today for a minor update to email addresses.
Fixes #918
Was there there a reason not to tag the next release from the main branch? I think the v1.0 branch was purely created (temporarily) to do a security release without pulling in upcoming changes from main; while it may serve purpose to backport specific critical fixes to a v1.0.x release, I would consider tagging the next release from main instead
We'd still need a branch for some Go and CI fixes that can't be tagged on main without pulling in the working group changes. Given that even v1.0.1 was released from the branch, I'm still trying to understand the normal release process.
can't be tagged on main without pulling in the working group changes
Does that work contain backward incompatible changes, or is that because it's not yet complete? Mostly wondering if there's a need to have an "LTS-like" v1.0 branch if a v1.1.0 release is being worked on. Go modules doesn't work well (or at all) with release branches (if bases any pseudo version it creates on "last semver(ish) tag on the default branch"). Tagging releases from a release branch, not from the "default" branch, will make those tags be ignored, so (e.g.) when tagging v1.1.0 from the v1 branch, the main branch will still be versioned v1.0.1-<date>-<commit>.
Given that even v1.0.1 was released from the branch
It wasn't created from the branch; https://github.com/opencontainers/image-spec/commit/d60099175f88c47cd379c4738d158884749ed235 is in main (and was merged as part of https://github.com/opencontainers/image-spec/pull/734). It probably shows up as "part of" the v1.0 branch because that branch was created later on from the v1.0.1 tag ( in preparation of v1.0.2).
If I recall correctly, the v1 branch was created specific for the security release; normal releases would come from the default branch, but as v1.0.2 was a security release, the intent was to only contain those changes, so the (temporary) branch was created from the v1.0.1 tag. The intent at the time was to merge the security fix into the v1.0 branch, then merge the v1.0.2 tag back into main, which happened in https://github.com/opencontainers/image-spec/pull/878 (after which the v1.0 branch probably should've been deleted).
Unfortunately something went wrong in the process of publishing the advisory, as the temporary GitHub security fork contained two PR's; one targeting the v1.0 branch, and one targeting main (which should've been closed); when publishing the advisory, both PR's were merged automatically, so there were now two distinct commits with the security fix;
- https://github.com/opencontainers/image-spec/commit/0126d30a90249ba624d134266b662e1d661381f5
- https://github.com/opencontainers/image-spec/commit/693428a734f5bab1a84bd2f990d92ef1111cd60c
git log --grep GHSA-77vh-xpmg-72qh
commit 0126d30a90249ba624d134266b662e1d661381f5 (upstream/v1.0)
Merge: d600991 e3885ce
Author: Vincent Batts <[email protected]>
Date: Wed Nov 17 13:12:56 2021 -0500
Merge pull request from GHSA-77vh-xpmg-72qh
Advisory fix 2
commit 693428a734f5bab1a84bd2f990d92ef1111cd60c
Merge: 9a7a987 6ced3bd
Author: Vincent Batts <[email protected]>
Date: Wed Nov 17 13:12:55 2021 -0500
Merge pull request from GHSA-77vh-xpmg-72qh
*.md: bring mediaType out of reserved status
can't be tagged on main without pulling in the working group changes
Does that work contain backward incompatible changes, or is that because it's not yet complete? Mostly wondering if there's a need to have an "LTS-like"
v1.0branch if a v1.1.0 release is being worked on.
We want to give v1.1.0 some time in RC to allow implementations to be written and prove it out. And the changes we want to include in v1.0.3 after the working group commit will fix CI from breaking. My hope is this is the last v1.0.x release.
Go modules doesn't work well (or at all) with release branches (if bases any pseudo version it creates on "last semver(ish) tag on the default branch"). Tagging releases from a release branch, not from the "default" branch, will make those tags be ignored, so (e.g.) when tagging v1.1.0 from the v1 branch, the main branch will still be versioned
v1.0.1-<date>-<commit>.
Do you have more details on this. My google foo is failing and I'm not seeing it on my own projects where I do tagging on release branches. I see that when a project pulls from a newer commit, so if they update to @main, they'll see the last tag on the main branch + the date/commit hash (confusing but not unusable). But if they pull the most recent v1 using @latest, I think they'd get the latest tag even if it's on a branch. Maybe we're saying the same thing, I just want to be sure "ignored" doesn't mean more than that.
I can think of 3 options:
- Refuse #918 and close this.
- Accept this and tag a v1.0.3.
- Move the1.0 branch off of main rather than cherry picking into the branch. There would still be some cherry picked commits to include from after the WG additions to allow CI to pass.