mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
Release version 10.0.0 #136
Reference in New Issue
Block a user
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?
Originally created by @andrewrabert on GitHub (Dec 21, 2018).
Let's start jellyfin's version over with a 10.0.0 release. Then we can more away from the inappropriate dash versioning we have currently.
@LeoVerto commented on GitHub (Dec 22, 2018):
IMHO jumping straight to 10.0.0 is somewhat of a confusing move. I think that instead going to 4.0.0 would be a lot clearer and still give us a large enough buffer in regards to Emby's versioning (so as to not confuse users).
By the time (and if) they do "catch up" we've hopefully diverged far enough to be seen as more than just a fork and rather an entirely alternative piece of software.
@sparky8251 commented on GitHub (Dec 22, 2018):
Why not 1.x.y.z ?
1 = Current Jellyfin version
x = Major Emby API version
y = Minor Emby API version
z = Jellyfin hotfix version
Also, what @LeoVerto said. Do we really need a unique scheme?
@joshuaboniface commented on GitHub (Dec 22, 2018):
I agree with @nvllsvm on just doing a clean version break. @JustAMan suggested going down to 0.X but I'd rather us go up instead personally, since going down implies we've regressed somehow when we really haven't. Airsonic jumped from 6.X to 10 when they completed their forking, and I think following that model as @nvllsvm suggests is a good idea. 10.X.Y, with X being major feature releases and Y being bugfixes, is a nice clean consistent versioning for us that doesn't limit future growth and lets us do sensible release versions for all platforms.
Any version change would be confusing IMO, but we're not at all tied to Emby releases anymore this being a hard fork, so I don't see much purpose in referencing Emby API versions in our version. We can keep the backend "API version" separate, since that will remain
3.5.2.Xfor as long as we need.4.0seems arbitrary as well, as it's just one above Emby's versioning, and if they do eventually release a 4.0 (which is likely to be on their future roadmap) that will cause even more confusion. 10 is such a clear difference that there will never reasonably be a conflict, it's a nice round number, and makes it very clear we've forked and are moving on.I do think we need a unique versioning scheme, because our release cycle is not going to follow Emby's in any reasonable way, nor will it reference future versions of Emby at all. Trying to shoehorn
3.5.2into our versioning is just locking is down to their versioning scheme (which is obnoxious, I hate 4-segment versions) as of the fork, which won't match our plans going forward.@balasankarc commented on GitHub (Dec 23, 2018):
I assume this is following SemVer and 10 will be bumped to 11 when backward incompatible changes are made to APIs. Am I right?
@joshuaboniface commented on GitHub (Dec 23, 2018):
@balasankarc Yup! Basically I envision us being on 10.X.Y until we complete all the apps for ourselves, and break compatibility with the Emby 3.5.2 API, at which point we'd move to 11.X.Y.