Closed JuniorJPDJ closed 4 years ago
Can't we specify it by the version?
@wvffle No, we will do versions when it will be at least partially stabilized :v
are python modules following semver? Then we can do 1.0.0-alpha.3
And of course not publish the package.
Or actually publish as it's alpha
@wvffle they do, but imo for this level of alpha 0.X.X is much better
s/does/do/
Then I opt to use 0.0.1-alpha.1
The worst part about versioning it in this state is that we will need to grow version in both projects 23589423598 times a week. Both would need new pull requests. For this moment I'd totally stay with commit hash.
That's where semver resolves this problem. If poetry is implementing it correctly then we can add ^0.0.1-alpha
to dependencies and when we'll bump the alpha number, it should install the newest one
I mean, we bump version in generic repo and then when we run poetry install
in this repo, it should always use newest alpha
@wvffle So we could just dump specifing commit version and it would be the same atm and we already had conversation about specifing dep version so it keep working
@JuniorJPDJ eg. today changes would totally break old versions if commit hash wasnt specified
@JuniorJPDJ semver is cool if api already stabilized at least a bit but it still didnt
@JuniorJPDJ eg. today changes would totally break old versions if commit hash wasnt specified
That's why we're still in alpha. Don't expect that software in alpha stage will be backwards compatible
@wvffle And we already use semver, look at version definition in pyproject file
A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.
Taken from semver.org
Nvm