Use split version publications

05nelsonm / kmp-tor-binary

Apache License 2.0

5 stars 2 forks source link

Use split version publications #170

Closed 05nelsonm closed 8 months ago

05nelsonm commented 9 months ago

binary-core and binary-core-api modules should be released as 0.1.0, while the binary module (and future binary-pt modules) follow the versions for the binaries they contain.

binary-core will only every change when support for a new architecture is added for Jvm/Node.js
binary-core-api will only every change if new Installer.Paths are needed (such as adding support for obsf4 and snowflake pluggable transports. Those Installer.Paths can be added beforehand as well, so a new release for it is not needed
Will definitely need to keep binary-core and binary-core-api release versions in sync, even though binary-core does not depend on binary-core-api.

05nelsonm commented 9 months ago

This also makes publishing things much simpler, as darwin targets always take forever. If can publish an update for tor only (and not all modules) it'd save a lot of headache.

05nelsonm commented 8 months ago

Should also rename binary-initializer to binary-core-initializer so publication name space is consistent.

05nelsonm commented 8 months ago

If split versioning is going to be a thing, mine as well migrate everything to kmp-tor instead of having 2 repositories..... :thinking:

This repository's version control is blown up from the inclusion of resources (my bad).
Will be able to perform integration tests on produced binaries with kmp-tor before publication.
Everything will be housed in a single repo making it easier for people to grok (for the most part).
The 1.x.x branch can still publish under the same git tag to give people lead time to migrate to 2.0.0 until it can then be archived and dropped.

05nelsonm commented 8 months ago

If split versioning is going to be a thing, mine as well migrate everything to kmp-tor instead of having 2 repositories..... 🤔

This repository's version control is blown up from the inclusion of resources (my bad).

Will be able to perform integration tests on produced binaries with kmp-tor before publication.

Everything will be housed in a single repo making it easier for people to grok (for the most part).

The 1.x.x branch can still publish under the same git tag to give people lead time to migrate to 2.0.0 until it can then be archived and dropped.

Actually, that is confusing as hell and presents a real problem tracking things. What would be better is to move those modules to a separate repository, kmp-tor-core, with it's own release cycle and what not.

05nelsonm commented 8 months ago

Moved to https://github.com/05nelsonm/kmp-tor-resource and https://github.com/05nelsonm/kmp-tor-core