Release sub-projects separately

[samuel-rufi]

Hi @jbolda,

we would like to use your Covector CI plugin to automatically manage releases for our repository containing multiple packages. Unfortunately I'm not really sure how to configure it correctly to release packages separately.

This is our repository: https://github.com/samuel-rufi/wallet.rs/tree/develop/bindings
We would like for example release the nodejs-binding package but wait with release of java-binding package. Is this possible to do?

I tried to deactivate version and publish fields for java-binding using https://github.com/samuel-rufi/wallet.rs/blob/develop/.changes/config.json but in the case there exist new changefiles for both nodejs-binding and java-binding, the "Version Changes PR" will also "close" the java-binding changefiles even if that package is deactivated. And since it "closed" the java-binding changefiles already when doing a Java release later the CHANGELOG will miss the changefiles.

Do I use changefiles in the wrong way?
Do you maybe have an example of a workflow supporting different packages that need to be released separately?

Many thanks in advance,
Samuel

[samuel-rufi]

@jbolda do you have any tips? many thanks

[jbolda]

@samuel-rufi, we currently don't have a great way to automate / semi-automate the release of packages separately. There are a lot of situations laced with nuance that make it difficult to handle. I haven't figured a way to handle it without any input from the user. Even then, I don't know what input would make sense to help someone manage it.

Separate languages is a pretty clear delineator, but if one language bundles and includes assets from another then it is a pretty hard dependency. If you always want to manage them completely separate and there are no dependencies, we could maybe handle this by having multiple .changes folders.

As an aside, what does your versioning for java look like? Are you using that package.json as a cheeky way to hold the version?

[samuel-rufi]

Hi @jbolda, yes our package.json file in Java is just a way to hold the version. Having multiple .changes folders would make separate releases possible I think, seems like a great solution to me!

Or maybe even some sub-folder structure (but I guess this might be a bit more complicated):
.changes/config.json
.changes/java
.changes/node-js

Many thanks for the help.

[jbolda]

I have been thinking a bit about this and to really reasonably manage it feels like we need to CLI to understand that it has "children" config that is intended to treat differently.

Were you able to test some of this implementation out? What is feeling painful with it?