Opened 6 years ago

Closed 19 months ago

#10289 closed task (fixed)

Update HAIKU_VERSION to something more future proof

Reported by: mmadia Owned by: bonefish
Priority: normal Milestone: R1/beta1
Component: Build System Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #11969
Has a Patch: no Platform: All

Description (last modified by mmadia)

build/jam/BuildSetup currently defines HAIKU_VERSION = r1~alpha4_pm .

Perhaps something along the lines of r1~pre_alpha5 would be more apt?

Upon each release, we could version the next release to be another alpha (or another beta, once in beta stage). This would prevent naming issues due to releasing an unanticipated alpha, when the current version would be named r1~pre_beta1.....

Change History (5)

comment:1 by mmadia, 6 years ago

Description: modified (diff)

comment:2 by bonefish, 6 years ago

wiki:PackageManagement/BuildingPackages#VersionStrings explains how versions are compared. It means r1~pre_alpha5 >= r1~alpha5. We only have one pre-release level in the version string; a pre-release of a pre-release cannot be expressed.

I would suggest to use as a the version string of an official release only the name of that release without repository revision, e.g. "r1~alpha5". For unofficial/master versions I would pad the version string of the previous official release to include all version components we're ever going to use and append the repository revision, e.g. "r1~alpha5.0_hrev12345" or "r1~alpha5.0.0_hrev12345". That keeps everything in order regardless of what the name of the next official release is.

Basically the build system already supports that scheme. The only thing missing is a way to disable appending the repository revision for official releases.

comment:3 by pulkomandy, 5 years ago

Type: enhancementtask

comment:4 by pulkomandy, 5 years ago

Blocking: 11969 added

(In #11969) On the versionning scheme for Haiku: more details in #10289.

So basically the release will have a version of R1~alpha5.0 or R1~beta1.0 (no hrev info). Anything built for a specific nightly will be R1~alpha5.0~hrev44444, which is greater than the release version number in our versionning scheme.

The package manager needs no change. All packages for a release need to be built while running that release, or an older nightly (which would have a version lile R1~alpha4_pm~hrev33333) so it is installable on alpha5.

comment:5 by waddlesplash, 19 months ago

Resolution: fixed
Status: newclosed

The release has been branched, version was bumped in hrev52295.

Note: See TracTickets for help on using tickets.