onflow
Versioning and import problems
Issue To Be Solved
I see a lot of imports with commit instead of version on master. This is not so healthy, and makes it really hard to contribute. I am creating the issue in here, but it is general problem with all flow repositories.
Suggest A Solution
Every merged PR should automatically increase relevant version[0] part and automatically tag.
- Every bug fix should increase the patch version
- Every new backwards compatible feature, should increase the minor version
- Every breaking API change should increase the major version
Also for tracking dependencies, there are few services ( and GitHub Actions )
- https://github.com/marketplace/actions/dependent-issues
- https://www.dpulls.com/#features
- https://github.com/marketplace/actions/pr-dependency-check
It would be also nice to have to auto create issues for dependant projects for every major version bump.
[0] https://semver.org
PS: Also can be very good to have a project page, to show what is being worked on etc. I had some free time, tried to make some PRs, was little hard to find out what I can work on.
I completely agree and have already talked with everyone to not do that in the future. This time it happened that Cadence team wanted to get ahead with changes and made those changes on specific commits. We already agreed this was not a good tactic and after things are tagged they will go back to normal. @bluesign
I've implemented mentioned dependent action, that was a good idea https://github.com/onflow/flow-cli/pull/596
For versioning there are a lot of alternatives like : https://github.com/marketplace/actions/github-tag-bump
https://github.com/marketplace?category=&query=bump+sort%3Apopularity-desc&type=actions&verification=
@bluesign do you think bumping for every PR is better? So currently we tag when doing a release. I can see value in making a tags on every PR merge, I just haven't done that in practice before and I wonder if that works well for you? Also the problem we currently have with CLI but also other repos (and I'm very aware of it and want to go solve it) is that we don't follow semver. I hate that semver doesn't nicely support software in beta since the tradition is to keep it major version at 0 but in reality all the changes that are breaking should increase the major. So hopefully after going 1.0 which I hope will be soon we will be then able to do the major increases as they should be done, before that I'm afraid this might be a bit of a problem to use.
@sideninja Actually avoiding breaking change with semver is pretty easy. It is just about separating your consumer facing interfaces and internal ones. Also it is more critical in libraries then user facing applications.
CLI can stay ( and should stay in version 0 ) but flowkit following semver has great advantages. Actually if you manage to extract FlowKit from CLI, I don't even think CLI needs to follow semver.
When there is a version bump, if it is not major one, you don't even have to check release notes, even with CI you can upgrade the dependencies. If it is minor, you can check on your free time, if some new feature arrived that can be useful later etc.
But biggest power is, constant pressure to not make breaking changes, which is really good motivator. Instead you deprecate stuff and some time in future you make a one big major release. ( spring cleanup ) This has huge advantage, if your replacement API has a bug, it is not critical anymore, because users now have a fallback till next major release.
Nice, good advice, thank you. I want to take flowkit out soon and actually do a bigger refactor and after that make it 1.0 and start following semver. The refactor will include accumulated ideas in the issue https://github.com/onflow/flow-cli/issues/493 and hopefully we will be able to soon start on that. I agree completely that CLI and flowkit are two separate things, I always had that in mind. I just kept them under rough until flowkit becomes mature enough, and I think that time has come if not for other reasons then due to usage in other projects. We should automate most of the things at that point, also making sure the dependabot works etc.
Dependencies versions are back to normal, with exception of LS which until extracted from Cadence is a hustle to reference by tagged version due to circular dependency.