Separate example and assembly version and update Cargo deps

icerpc / icerpc-csharp

A C# RPC framework built for QUIC, with bidirectional streaming, first-class async/await, and Protobuf support.

https://docs.icerpc.dev

Apache License 2.0

101 stars 13 forks source link

Separate example and assembly version and update Cargo deps #3961

Closed externl closed 5 months ago

externl commented 5 months ago

This PR separates the "version number" used for the examples and the IceRPC assemblies. It also updates the slices cargo dep.

Additionally it moves the testing of the examples to a separate step job independent of the src build.

pepone commented 5 months ago

How would we add examples for new features if examples are built against the released version? How would we know if an update breaks an example?

externl commented 5 months ago

How would we add examples for new features if examples are built against the released version? How would we know if an update breaks an example?

To me, the most important thing is that these examples use the published NuGets, no building required.
These 0.X.x branches are about patch fixes, we probably shouldn't adding new features. If we really need to I'm sure we can come up with a solution.
We could run an additional build of the examples with a published src build by doing dotnet build /p:Version=... after a local publish.
We really shouldn't be making changes that break examples, and we shouldn't use these examples as a way to enforce "binary compatibility".

pepone commented 5 months ago

How would we update the version when we want to release?

Do we have to first release the next version for example, v0.3.1, and after publishing the new packages we upgrade the examples version, or are you thinking of a different workflow?

externl commented 5 months ago

Do we have to first release the next version for example, v0.3.1, and after publishing the new packages we upgrade the examples version

Exactly this.

bernardnormier commented 5 months ago

How would we add examples for new features if examples are built against the released version?

Easy: we don't add new features (at the very least new features that affect the existing examples) on released branches.

How would we know if an update breaks an example?

It is desirable to configure the example build to use the latest preview if available (typically available from a local build). I assume it's doable but not the default.

externl commented 5 months ago

Yes, when we merge to main we need to make sure not to take these files.

externl commented 5 months ago

Is main far behind 0.3.x?

pepone commented 5 months ago

Is main far behind 0.3.x?

No but, we want to test with a different version in main, don't we? Or do we plan to keep examples in main building against latest released version, would be difficult for new examples?

externl commented 5 months ago

No but, we want to test with a different version in main, don't we? Or do we plan to keep examples in main building against latest released version, would be difficult for new examples?

For main, I think we should look into publishing NuGet packages to a registry that allows replacing a package. Hopefully we can do this with GitHub packages. When we can up the package nightly on for every commit to main. Then we can build the examples which those packages.

Another option is to have a nightly tag that has NuGet artifacts that we could use.