Publish up-rust v0.1.0 to crates.io

[PLeVasseur]

Hey @stevenhartley, @sophokles73, @dakrbo:

With the issue closed regarding the implementation of the SDK, do you think now makes sense to publish a v0.1 to crates.io?

It's a pre 1.0 release, so we can still make breaking API changes like the one suggested to the listener type definition.

[sophokles73]

Before we do that, we will need to perform an initial Release Review. After that, we can do subsequent releases for a year until the yearly progress review.

@stevenhartley you should be able to trigger the review using the Eclipse Project Management Infrastructure (PMI).

@dakrbo I would suggest to set the version of the crate to a SNAPSHOT version of the upcoming release in order to clearly point out that the code on the main branch is work in progress towards a release but does not reflect the release (yet). In our case that might be something like 0.1.5.SNAPSHOT. When we do the release, i.e. create the corresponding tag in the repository, we set it to 0.1.5 and then change it to the next upcoming SNAPSHOT version, e.g. 0.1.6.SNAPSHOT.

[PLeVasseur]

Ah okay, good to learn about this. Thanks for the links!

Is this the bit that you think means we can't release to anywhere outside, e.g. to crates.io: Milestone builds can be hosted wherever the project team hosts downloads. May well be, I'm a newbie to the Eclipse Foundation process 😅

Would it make sense to follow the SemVer spec? Gotta respect they wrote down the BNF representation.

I suppose we'd be meeting SemVer spec if we did something like 0.1.5-SNAPSHOT.1, using SNAPSHOT.1 as our <pre-release> identifier. Then we could increment the .1 -> .2 when we had further refinements.

I kinda like this because it lets us use the first three digits of the SemVer in order to reflect which version of the uProtocol spec we comply with until uProtocol itself is stable enough for us to move to calling it 1.5.0 or whatever the current version of uProtocol is.

What do you think?

[PLeVasseur]

Maybe a separate question to @stevenhartley:

Does uProtocol spec version according to SemVer? In other words:

Bug fixes not affecting the API increment the patch version, backward compatible API additions/changes increment the minor version, and backward incompatible API changes increment the major version.

To where if e.g. the uProtocol spec changed to say, remove a uTransport interface or change the signature of one of them, would that entail a major bump? Feels kinda drastic while the details are still being worked out to me.

Perhaps the uProtocol spec could also follow a similar idea that @sophokles73 had regarding SNAPSHOT releases while things are being defined.

What do you think? Could help keep the different implementations sorted out as to which release or SNAPSHOT they were compliant with.

[sophokles73]

Would it make sense to follow the SemVer spec?

Yes, definitely, the Eclipse Development Process actually mandates it. Projects in the incubation phase usually use a major version < 1 so that they are flexible regarding backwards compatibility. Then, later, when the external API becomes more stable and the project has learned the ropes of the EDP, the project prepares its 1.0.0 release and has its Graduation Review in order to exit the incubation phase.

[sophokles73]

I suppose we'd be meeting SemVer spec if we did something like 0.1.5-SNAPSHOT.1, using SNAPSHOT.1 as our identifier. Then we could increment the .1 -> .2 when we had further refinements.

FMPOV we would use 0.1.5.SNAPSHOTinstead ...

[PLeVasseur]

I suppose we'd be meeting SemVer spec if we did something like 0.1.5-SNAPSHOT.1, using SNAPSHOT.1 as our identifier. Then we could increment the .1 -> .2 when we had further refinements.

FMPOV we would use 0.1.5.SNAPSHOTinstead ...

Gotcha. Seemed like to me we'd need a dash instead of a dot between the patch number and the <pre-release> identifier:

<valid semver> ::= <version core>
                 | <version core> "-" <pre-release>
                 | <version core> "+" <build>
                 | <version core> "-" <pre-release> "+" <build>

But I'm up for hearing the context behind your POV.

And ultimately not a huge deal from my POV.

[sophokles73]

I stand corrected. Then it is 0.1.5-SNAPSHOT, isn't it? However, I guess now I get what you where trying to achieve. You want to be able to actually do a pre-release version, i.e. you want to publish something to crates.io that has version 0.1.5-pre1 and then later publish 0.1.5-pre2 etc.

My point regarding using 0.1.5-SNAPSHOT as the version in Cargo.toml was more that we should make it clear that the stuff on the main branch is work in progress towards a particular version. But we can also use 0.1.5-pre in Cargo.toml if you like that better.

In any case, I do not see a problem with publishing 0.1.5-pre1 (and successive pre-releases) to crates.io. We can even publish those pre-release versions without having to undergo the Release Review first, according to the Pre-Release Milestone Builds section of the EDP.

[PLeVasseur]

I stand corrected. Then it is 0.1.5-SNAPSHOT, isn't it? However, I guess now I get what you where trying to achieve. You want to be able to actually do a pre-release version, i.e. you want to publish something to crates.io that has version 0.1.5-pre1 and then later publish 0.1.5-pre2 etc.

Exactly! To get a version out there.

My point regarding using 0.1.5-SNAPSHOT as the version in Cargo.toml was more that we should make it clear that the stuff on the main branch is work in progress towards a particular version. But we can also use 0.1.5-pre in Cargo.toml if you like that better.

In any case, I do not see a problem with publishing 0.1.5-pre1 (and successive pre-releases) to crates.io. We can even publish those pre-release versions without having to undergo the Release Review first, according to the Pre-Release Milestone Builds section of the EDP.

Sounds good. I suppose we'd do 0.1.5-pre.1 looking at the spec:

<pre-release> ::= <dot-separated pre-release identifiers>

<dot-separated pre-release identifiers> ::= <pre-release identifier>
                                          | <pre-release identifier> "." <dot-separated pre-release identifiers>

<pre-release identifier> ::= <alphanumeric identifier>
                           | <numeric identifier>

And could follow with 0.1.5-pre.2, 0.1.5-pre.3, ...

What do you think?

[sophokles73]

I am not sure why you want to use -pre.1 instead of just -pre1. Both seem to comply with the grammar so I guess it comes down to personal taste. I have no strong feeling about it but I have to admit that I have not seen a version identifier like 0.1.5-pre.2 in my professional career so far.

That said, IMHO we should make sure that we use a distinct version identifier on the main branch in order to clearly distinguish between a build from HEAD vs a published pre-release version. For example, I can imagine using e.g. 0.1.5-pre or 0.1.5-SNAPSHOT on main branch ...

[PLeVasseur]

All righty. I think we agree, but let me write it out to make sure.

So to sum up,

• Build from head: 0.1.5-SNAPSHOT
• Prerelease cuts (we'd release one of these to crates.io): 0.1.5-pre1, 0.1.5-pre2, ...
• First release, when it's ready: 0.1.5

I've only ever released one crate. Who should release it? Maybe we should have @stevenhartley release it so he's the initial owner and then he could add others as needed, e.g. you, Daniel, and me.

WDYT?

[AnotherDaniel]

Sounds good for me - however, and without wanting to snowball this into a huge discussion: it might be a good idea to have more than one project contributor (someone with rights to create releases, merge PRs etc) for the SDK code base, when we publish to crates.io. Reduce the bus factor, increase the bandwidth for dealing with things that come up, etc

[PLeVasseur]

Sounds good for me - however, and without wanting to snowball this into a huge discussion: it might be a good idea to have more than one project contributor (someone with rights to create releases, merge PRs etc) for the SDK code base, when we publish to crates.io. Reduce the bus factor, increase the bandwidth for dealing with things that come up, etc

Yup agree with this. Sounds like there's some process to do so with Eclipse tho. Not sure if @stevenhartley has any insight on if there's any way to do this in a streamlined manner.

btw -- @stevenhartley -- sometime coming up we should sit together w/ @AnotherDaniel & @sophokles73 to have them walk us through publishing uprotocol-rust to crates.io.

[sophokles73]

The Eclipse Zenoh project has also added the project's GitHub bot as an owner to the Zenoh crates. This makes a lot of sense to me, in particular because we can then use an API token issued to that bot (account) instead of using a personalized token. We can then easily set up a GitHub workflow for publishing to crates.io which could be triggered by creating a tag ...

[stevenhartley]

We have done this with maven central to be able to publish the Java artifacts, you can checkout the github actions (took weeks to get right with the EMO).

[AnotherDaniel]

With the URI rework coming in, and maybe a couple of hands-on learnings in the RpcMapper area that are going to come soon - would it make sense to raise this issue up again, and aim for a release to crates.io?

Aside from the code/content changes we'd like in, are there any operational issues that we need to address to do a prober public release?

[evshary]

I have one question here: Should up-client-xxx library use the same version as up-rust? Or maybe each of up-client-xxx can just maintain their version and up-rust do nothing to it?

[AnotherDaniel]

I would expect that all crates/implementations using up-rust would use the same (latest release) version. Not least because they are jointly using types defined in up-rust... also, a wild fragmentation of up-rust customisations by every -client sounds like something to avoid at all costs, to me...

[evshary]

I would expect that all crates/implementations using up-rust would use the same (latest release) version. Not least because they are jointly using types defined in up-rust... also, a wild fragmentation of up-rust customisations by every -client sounds like something to avoid at all costs, to me...

Agree with that. This is also how Zenoh eco-system works now.

[AnotherDaniel]

While we're having that conversation - is there a change for up-client-zenoh-rust to pick up the current/latest changes in up-rust? I am in the situation where I depend on both, and have one of these clashes right now after carelessly rebasing some of my up-rust changes on the latest changes...

[PLeVasseur]

Aside from the code/content changes we'd like in, are there any operational issues that we need to address to do a prober public release?

So the idea would be to get up-rust updated to 1.5.8 spec when that settles down and aim for using that for an initial release?

[evshary]

While we're having that conversation - is there a change for up-client-zenoh-rust to pick up the current/latest changes in up-rust?

I'll do that these days. Since there are some changes on up-rust, I should indeed check how it works in up-client-zenoh-rust.

[sophokles73]

The only imminent issue to be resolved before doing a 0.1.0 release is #122. However, that would then be based on uProtocol Spec v1.6.0-alpha.2 ...

[PLeVasseur]

The only imminent issue to be resolved before doing a 0.1.0 release is #122. However, that would then be based on uProtocol Spec v1.6.0-alpha.2 ...

Yeah... we'd have to note in the README.md which version of the spec we comply with.

[sophokles73]

v0.1.0 has been published to crates.io