search

serverlessworkflow / sdk-typescript

Typescript SDK for Serverless Workflow
https://serverlessworkflow.io/
Apache License 2.0
62 stars 16 forks source link

added workflow deploy npmjs registry #116

Closed antmendoza closed 3 years ago

antmendoza commented 3 years ago

Signed-off-by: Antonio Mendoza Pérez antmendoza@gmail.com

Many thanks for submitting your Pull Request :heart:!

What this PR does / why we need it: close #87

Special notes for reviewers: I have changed the package version because there is already a package published with 0.6 version, my mistake testing the deployment workflow from my repo

The secret with name NODE_AUTH_TOKEN is already setup in this repository.

Additional information (if needed):

JBBianchi commented 3 years ago

I think version patching should be done via CI/CD I think (based on the tag + latest published version for instance). Maybe semantic release could also be of use ?

antmendoza commented 3 years ago

that would be great @JBBianchi for now I am changing the package json to version 1.0.0 and create a release branch and release from that branch.

I am adding a property "schemaVersion" to the package.json to keep working the "tools:download-schemas" functionality

JBBianchi commented 3 years ago

Don't you think we should follow the specification version. We could have to branches/tags/ version:

Main / 0.7 -> npm 0.7.x 0.6 / 0.6 -> npm 0.6.x

When the specs goes to v1.0.0: Main / 1.0 -> npm 1.0.x 0.7 / 0.7 -> npm 0.7.x 0.6 / 0.6 -> npm 0.6.x

Idk if it makes sense

JBBianchi commented 3 years ago

IMO, it's the easier for the dev that have to choose a version. Let's say his company have a workflow running on v1.2 but the spec is at v2.1, if the SDK packages follow the same versioning, it's easy to pick the right one. If not, then it's a bit difficult to know which version of the SDK correspond to which version of the spec.

antmendoza commented 3 years ago

That is a good point, but if look into the go and java sdks (not the .net sdk) they have different versions of the spec.

Dev only have to look into the documentation to figure out what version to use.

tsurdilo commented 3 years ago

Software (SDK / Synapse) released do not have to follow the spec releases numbers at all. I think also following java / go sdk and coming up with your own release numbers based on best practices for your sdk type would be great.

tsurdilo commented 3 years ago

@JBBianchi we have these mapping tables - https://github.com/serverlessworkflow/sdk-java#status This is nice cause in case there are any bugs we find out after the release we can just release like a 1.0.1 from the 1.0.x release branch with the backported fix

Regarding the easy to pick up - the DSL mandates the "specVersion" property and in SDKs validators we should check if that version matches the sdk release that is being used. wdyt?

antmendoza commented 3 years ago

Regarding the easy to pick up - the DSL mandates the "specVersion" property and in SDKs validators we should check if that version matches the sdk release that is being used. wdyt?

👍

@tsurdilo specVersion has been introduce in the 0.7 spec version, isn't it?

tsurdilo commented 3 years ago

@antmendoza ahhh yes ..i forgot about that :) sorry

tsurdilo commented 3 years ago

@antmendoza i think for 0.6 you can assume it is 0.6 spec version, don't think anyone is writing dsl using any prior releases anyways. Yeah starting with 0.7 we will be able to validate based on specVersion param

JBBianchi commented 3 years ago

It makes sense for the sdk to have it's own version in the way that if the surface api changes, the minor version (or even major if breaking) is affected following the semver guidelines. I just felt it was easier to identify which sdk version support which spec version but it's not mandatory, the compatibility table should work as well.