Comments (23)
My 0.02c on releases and versions:
- At least in the context of
sigstore-python
, I'd like this repo to publish a separate Python package that we can depend on (i.e., it should be on PyPI). We currently have all of the appropriate packaging metadata for this already set up (it's currently namedsigstore-protobuf-specs
), so it's just a matter of automating the publishing of releases for that project name. I'm happy to do that work, whenever we're ready to do an initial (pre/rc?) set of releases. - At least for the Python bindings, it would be nice if the release workflow was on GitHub Actions π -- there's a lot of mature CI tolling for PyPI + GitHub already (like
gh-action-pypi-publish
) that we can ideally reuse!
from protobuf-specs.
I am okay abandoning the "one tag for all releases" model and it sounds like given the complexity across many different packages the "semi-manual" flow makes sense.
In that case, I can throw together some metadata + CI work to get an initial alpha version of the Python package published! I'll have that ready this afternoon, if that works for everyone else.
from protobuf-specs.
I'm not sure I have a way to detect changes in Java since we don't check anything in -- maybe we can compare the build result with the last release (will have to wait till we have an actual release), as the build is configured to be reproducible.
Sometimes projects with multiple artifacts (within java) tend to just do releases across the whole suite since it feels consistent (but not functionally different for many artifacts).
I'm okay just always doing releases on all languages if the proto changes or even if one language requires a build update.
from protobuf-specs.
I am okay abandoning the "one tag for all releases" model and it sounds like given the complexity across many different packages the "semi-manual" flow makes sense.
from protobuf-specs.
(I'll need to coordinate with one of the repo owners/admins to get the PyPI API token added to the repo's secrets.)
from protobuf-specs.
Alright, so after some discussion, I think this is the strategy python and java will do:
- tag by
release/<language>/version
(ex:release/python/v1.0.0
) - this should trigger the language specific release process
from protobuf-specs.
PyPI appears to work! https://pypi.org/project/sigstore-protobuf-specs/0.0.1a1/ (CC @woodruffw)
from protobuf-specs.
Based on the conversation above, I think this issue can be resolved. To summarize:
- Each language in this repository will use a
release/$lang/v$version
tagging scheme, and will be configured with a dedicated release workflow that matches on that tagging scheme - The release workflow will be "semi-manual," meaning that a human has to manually cut the tag and releases are not synchronized across languages
- Language bindings will not synchronize on minor or patch versions.
Does that sound correct/accurate to you @znewman01 @loosebazooka?
from protobuf-specs.
Would also like to figure out the pre-GA strat so I can import and use this stuff in sigstore-java.
from protobuf-specs.
Ahh, I assume pre-GA strat will be "semver lite" (minor version bumps => breaking change, patch bumps => anything nonbreaking) but no guarantees.
from protobuf-specs.
I think your proposal looks good @znewman01, the bundle mime time as of no is proposed to only contain major and minor version, which I think is ok with your proposal, as patch versions should not change the generated code.
We should document how to work with releases, and make sure that we capture how the mime type should follow the same versioning as the release it self.
from protobuf-specs.
Copying from #26. @tetsuo-cpp writes>
This repository is eventually going to contain code to publish packages to each language ecosystem's respective package index. We need to figure out some scheme of keeping these version numbers consistent. So for instance, the v0.0.5 version of this package should be generated from the same set of Protobuf specifications regardless of whether we download it for Python, Java, etc.
Context: #25 (comment)
from protobuf-specs.
So what's the plan on credentials. Do we want release builds to run on cloud build in the sigtsore gcp project and use secrets from there to do releases?
from protobuf-specs.
from protobuf-specs.
Some open questions about triggering a release
Do releases automatically trigger on new tags OR should each release be manually initiated
- Auto means means we have nicer automation, but failure recovery is a bit confusing when releasing multiple artifacts. When a build does fail, do we create a new tag an a new release for all artifacts?
- Manual gives us a lot of flexibility but with an extended checklist for the releaser.
from protobuf-specs.
I used to be in favor of automatic releases on new matching tags (i.e. v\d+\.\d+\.\d+
), but I've had better experiences recently with a semi-manual flow: the releaser is responsible for creating the tag and publishing the GitHub Release, after which point a GitHub Actions workflow takes over the rest.
- When a build does fail, do we create a new tag an a new release for all artifacts?
IMO this is a good reason to not keep tags/versions between all packages in strict lockstep. A pattern I've used before here is to have a distinct release pattern for each package in the repository, e.g.:
release/pb-python/v1.0.0
...where only the major version component indicates compatibility with a particular (matching) version of the protobuf specs. But that deviates slightly from what @znewman01 proposed π
from protobuf-specs.
the releaser is responsible for creating the tag and publishing the GitHub Release, after which point a GitHub Actions workflow takes over the rest.
Can you elaborate a bit more on this? I'm not really following. Would there be one workflow for the Release and another which pulls the artifacts and publishes them to each language's canonical package registry?
When a build does fail, do we create a new tag an a new release for all artifacts?
We could have a workflow that does not publish anything before all builds succeeds right?
from protobuf-specs.
We could have a workflow that does not publish anything before all builds succeeds right?
There's also the case that the language specific release workflow could break and needs an update.
from protobuf-specs.
There's also the case that the language specific release workflow could break and needs an update.
I'm not sure if was in this issue or somewhere else, but we also talked about having a single -devel
version being published, if that's the case, we should detect things like this before a release is cut.
from protobuf-specs.
I.e each update to the repo would publish a new development version.
from protobuf-specs.
Can you elaborate a bit more on this? I'm not really following. Would there be one workflow for the Release and another which pulls the artifacts and publishes them to each language's canonical package registry?
What I mean is something like sigstore-python
's release workflow: https://github.com/sigstore/sigstore-python/blob/main/.github/workflows/release.yml
In that case, there's only one workflow for the release, and the workflow does its own build for the release internally. Since this repo has multiple languages/packages, we'd probably want release-python
, release-go
, etc. instead, but the basic structure would be the same.
from protobuf-specs.
I am one of those folks so happy to be that person. Just sent you a message on Slack.
from protobuf-specs.
Awesome! Thanks a ton @znewman01!
from protobuf-specs.
Related Issues (20)
- Drop namely/protoc-all in favour of a custom Dockerfile? HOT 3
- Optimize the Rust codegen HOT 2
- Stabilize the bundle format HOT 5
- jsonschema: setting `--platform` breaks targets on aarch64-darwin HOT 1
- jsonschema: Docker container dependency conflict
- Create a script to generate CHANGELOG
- Release v0.2.1 HOT 4
- CA uri provide grpc uri as well? HOT 1
- Python: switch release workflow to trusted publishing
- Add definitions for in-toto statements? HOT 3
- Bundle Media Type HOT 11
- Setup Ruby language bindings HOT 1
- FR: Separate canonicalized_body from TransparencyLogEntry? HOT 7
- Removing the root cert from the bundle's cert chain? HOT 48
- Rust bindings HOT 1
- [Proposal] Require inclusion proofs HOT 1
- Maintain a CHANGELOG of protobuf changes between versions HOT 2
- Upload v0.2.0 to Maven Central HOT 9
- `buf` tooling to abstract over multi-language bindings
- [RFC] Rehome `io.intoto` namespace under `dev.sigstore`? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from protobuf-specs.