Lbrycrd needs version scheme #26
Labels
No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
consider soon
Epic
good first issue
hacktoberfest
hard fork
help wanted
icebox
Invalid
level: 0
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
priority: blocker
priority: high
priority: low
priority: medium
resilience
soft fork
Tom's Wishlist
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
work in progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbrycrd#26
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Need to figure out how versions will be set
da53f17a28/src/clientversion.h
Sensible proposal :
Major , Minor follows Bitcoin Core code (would be 12.0 currently)
Client version build is used to track major lbry releases within the Core code base ( Increment from 0 up to 99). Current version could be 1 after soft fork at
874948ec59
One nit - major.minor is currently
0.12
not12.0
.When you say client version, what do you mean?
Regarding tracking lbry releases - I don't understand what happens when it gets reset to 1; it seems that something else should get incremented when that happens.
You are right about the first point, to clarify , the Bitcoin Core version we are using is 0.12.0 (it is not really 0.12.99 , the 99 is a place holder indicating that it is not a release version).
We use the first three numbers from the Bitcoin core version we are using, and than the last number gets incremented according to our releases. So we get 0.12.0.1 to 0.12.0.2 etc... I would only increment the release for major changes such as a soft fork, not minor changes like to the RPC commands. The primary purpose would be to be able to tell which client version nodes are running in the event of soft forks. For minor changes we can do a git tag such as 0.12.0.1 release 1/2/...etc.
So current version should be 0.12.0.1 and release 2 I believe.
How is this going to handle future pulls from upstream?
For example , if bitcoin release is 0.12.0.1 our release is 0.12.0.X where X is some custom number we use. The last number in Bitcoin is for client builds which are usually not major changes, so we can use it to keep track of changes unique to Lbrycrd.
closed as https://github.com/lbryio/lbrycrd/pull/37