search

hyperledger-archives / quilt

Hyperledger Quilt - An implementation of the Interledger Protocol
https://wiki.hyperledger.org/display/quilt
Apache License 2.0
218 stars 79 forks source link

Formalize versioning and release process #95

Closed adrianhopebailie closed 6 years ago

adrianhopebailie commented 6 years ago

@earizon and @sappenin initiated a discussion around this in #90

Having read through the blog linked in the thread I found the following to be interesting and need our attention:

The version of all sub-modules should be the same as the version of the parent pom and all sub-modules should be released together.

I suggest we fix this in all our sub-modules but consider pulling some sub-modules out into their own project like crypto-conditions and the codec-framework as these don't make sense as modules that will be re-released with each new version of the Interledger components.

Also, given the changes with ILPv4 we may consider changing ilp-core to no longer depend on crypto-conditions...

I think part of our problem is that we are in a very experimental stage and are making breaking changes to the APIs regularly. The sooner we get out of that the better then we can follow a better release process.

On the one hand I agree with @earizon that SNAPSHOT releases are supposed to indicate that they are an interim state but I also think that if we change the API from one commit to another then that will break any applications that use the API and so this needs to be signaled by a version number change.

I propose that we say:

  1. If you submit a change that breaks any API then the version number must increment
  2. If you submit a change that doesn't break an API then it's okay to leave the version number unchanged if the change is being made on a SNAPSHOT.

Proposal

Let me know what you think of doing each of these:

  1. Put crypto-conditions in it's own repo and leave version at 0.5.0-SNAPSHOT
  2. Set versions of all modules and submodules to 1.0.0-SNAPSHOT with a goal of making a release following our call on 14 February
  3. Get the repo setup to use the maven-release plugin correctly and aim to make formal releases after our bi-weekly call unless there is an important bug-fix.
  4. Setup the CI to make a SNAPSHOT release every time we merge into master
sappenin commented 6 years ago

Agree with all suggestions - I can work on pulling out crypto-conditions into a new project.

@adrianhopebailie Should that still be in hyperledger? If so, what should we call it?

sappenin commented 6 years ago

Also, given the changes with ILPv4 we may consider changing ilp-core to no longer depend on crypto-conditions...

I would like to break the crypto-conditions project into sub-modules, one of which will be crypto-conditions-api that will basically just have interfaces and immutable-implementations (but not codecs, etc).

I propose that we pull that minimal dependency into ilp-core so that users of both libraries don't have to worry about having two different variants of something called "crypto-condition".

adrianhopebailie commented 6 years ago

I propose that we pull that minimal dependency into ilp-core so that users of both libraries don't have to worry about having two different variants of something called "crypto-condition".

Yes, I thought about that too. I think that would be a great idea.

Should that still be in hyperledger?

I actually think it should be in a public repo under @ripple but not sure if that's something we can do. Will find out.

adrianhopebailie commented 6 years ago

Crypto-conditions is now at: https://github.com/ripple/crypto-conditions