KolibriOS/kolibrios
12
4
Fork 11
Code Issues 78 Pull Requests 5 Projects Releases Activity

WIP: Changing the OS version retrieval API due to migration to Git #62

Closed
mxlgv wants to merge 2 commits from change-get-version-api into main
pull from: change-get-version-api
merge into: KolibriOS:main
Conversation 4 Commits 2 Files Changed 14 +132 -126
mxlgv commented 2024-03-31 01:42:03 +01:00
Owner
Copy Link

Changing the OS version retrieval API due to migration to Git.
The new versioning method is based on https://semver.org/ :
Git tag - major.minor.patch
major - changes when the kernel API is no longer compatible;
minor - change when compatible kernel functionality is added;
patch - fixing kernel bugs and driver/userspace changes.

  • Added script for getting version via git describe --tag --long;
  • The system function for obtaining the kernel/OS version has been fixed (SF 18.13);
  • The documentation for SF 18.13 has been updated;
  • Fixed version display in SHELL application;
  • Perhaps there are other places where the kernel/OS version is used and where this needs to be fixed;
  • Delete all $Revision$;
  • Made only for Tup, perhaps changes are needed for other ways to build the kernel.
Changing the OS version retrieval API due to migration to Git. The new versioning method is based on https://semver.org/ : Git tag - `major.minor.patch` `major` - changes when the kernel API is no longer compatible; `minor` - change when compatible kernel functionality is added; `patch` - fixing kernel bugs and driver/userspace changes. - [x] Added script for getting version via `git describe --tag --long`; - [x] The system function for obtaining the kernel/OS version has been fixed (SF 18.13); - [x] The documentation for SF 18.13 has been updated; - [x] Fixed version display in SHELL application; - [ ] Perhaps there are other places where the kernel/OS version is used and where this needs to be fixed; - [ ] Delete all `$Revision$`; - [ ] Made only for Tup, perhaps changes are needed for other ways to build the kernel.
mxlgv added 2 commits 2024-03-31 01:42:05 +01:00 
Signed-off-by: Maxim Logaev <maxlogaev@proton.me>
Signed-off-by: Maxim Logaev <maxlogaev@proton.me>
mxlgv requested review from rgimad 2024-03-31 01:54:55 +01:00
dunkaist commented 2024-03-31 03:42:01 +02:00
Owner
Copy Link

major - changes when the kernel API is no longer compatible;

This literally means that removal of sf18.11 will bump KolibriOS version to 1.0.0.
Then removal of midi-related syscalls will bump it again to 2.0.0.
Then removal of MENUET00 header will bump it to KolibriOS 3.0.0. I mean KolibriOS 3.0.0-0+.

> major - changes when the kernel API is no longer compatible; This literally means that removal of sf18.11 will bump KolibriOS version to 1.0.0. Then removal of midi-related syscalls will bump it again to 2.0.0. Then removal of MENUET00 header will bump it to KolibriOS 3.0.0. I mean KolibriOS 3.0.0-0+.
mxlgv commented 2024-03-31 03:59:34 +02:00
Author
Owner
Copy Link

major - changes when the kernel API is no longer compatible;

This literally means that removal of sf18.11 will bump KolibriOS version to 1.0.0.
Then removal of midi-related syscalls will bump it again to 2.0.0.
Then removal of MENUET00 header will bump it to KolibriOS 3.0.0. I mean KolibriOS 3.0.0-0+.

I don't think it's worth doing this. The next version we should have is obviously 1.0.0. Upgrading to 3x is pointless since versions 1.0.0 and 2.0.0 simply do not exist. That is, I propose to increase major with every API change(no longer compatible). I suggest increasing it by 1 during release if there have been any changes and even if there are several of them. But I want to note that in the master branch there will probably be code that does not match the version. That is, a situation may arise when we change the API but the version in the master will remain unchanged. But when preparing for release, we will have to check all the drivers and programs that are tied to the new version of the kernel and fix them.

> > major - changes when the kernel API is no longer compatible; > > This literally means that removal of sf18.11 will bump KolibriOS version to 1.0.0. > Then removal of midi-related syscalls will bump it again to 2.0.0. > Then removal of MENUET00 header will bump it to KolibriOS 3.0.0. I mean KolibriOS 3.0.0-0+. I don't think it's worth doing this. The next version we should have is obviously 1.0.0. Upgrading to 3x is pointless since versions 1.0.0 and 2.0.0 simply do not exist. That is, I propose to increase major with every API change(no longer compatible). I suggest increasing it by 1 during release if there have been any changes and even if there are several of them. But I want to note that in the master branch there will probably be code that does not match the version. That is, a situation may arise when we change the API but the version in the master will remain unchanged. But when preparing for release, we will have to check all the drivers and programs that are tied to the new version of the kernel and fix them.
Sweetbread removed review request for rgimad 2024-04-08 19:15:13 +02:00
Sweetbread requested review from rgimad 2024-04-08 19:16:55 +02:00
dunkaist reviewed 2024-04-10 17:08:37 +02:00
kernel/trunk/docs/sysfuncs.txt
@ -969,1 +960,3 @@
db 0,7,7,0
db major, minor, patch - git-tag;
db 0 - reserved for alignment to dword;
dw offset - number of commits after git-tag;
dunkaist commented 2024-04-10 17:08:37 +02:00
Owner
Copy Link

Do we need that offset at all? I have noticed that some people prefer to put unrelated changes to a single commit 'not to waste revision numbers'. My opinion is that we should care more about readability rather than revision numbers. Because the number of revisions is unlimited unlike the number of developers and amount of their time. Maybe switching to git is a great moment to drop revision numbers and all kinds of commit counters completely and use just hashes and release tags.

Do we need that offset at all? I have noticed that some people prefer to put unrelated changes to a single commit 'not to waste revision numbers'. My opinion is that we should care more about readability rather than revision numbers. Because the number of revisions is unlimited unlike the number of developers and amount of their time. Maybe switching to git is a great moment to drop revision numbers and all kinds of commit counters completely and use just hashes and release tags.
Sweetbread commented 2024-04-10 17:42:07 +02:00
Owner
Copy Link

Do we need that offset at all?

Yes. We're planning 2 image variants: release (versioned) and night build, where offset will show how far this image from release

I have noticed that some people prefer to put unrelated changes to a single commit 'not to waste revision numbers'.

'Cuz for people revision number is not just number, but almost version. Why to increment version if you just fix TYPO?
Also, as I understood, SVN can't push multiple commits. So, why not to put some minor changes in one commit?

My opinion is that we should care more about readability rather than revision numbers.

v0.7.7.6+12 is pretty readable, isn't?

Because the number of revisions is unlimited unlike the number of developers and amount of their time.

Wdym? This structure should be initialized while building by script

Maybe switching to git is a great moment to drop revision numbers

We do

and all kinds of commit counters completely and use just hashes and release tags.

  • Release tags for versions
  • Hashes for precise identification of a commit and searching
  • Offsets for night versions
> Do we need that offset at all? Yes. We're planning 2 image variants: release (versioned) and night build, where offset will show how far this image from release > I have noticed that some people prefer to put unrelated changes to a single commit 'not to waste revision numbers'. 'Cuz for people revision number is not just number, but almost version. Why to increment version if you just fix TYPO? Also, as I understood, SVN can't push multiple commits. So, why not to put some minor changes in one commit? > My opinion is that we should care more about readability rather than revision numbers. `v0.7.7.6+12` is pretty readable, isn't? > Because the number of revisions is unlimited unlike the number of developers and amount of their time. Wdym? This structure should be initialized while building by script > Maybe switching to git is a great moment to drop revision numbers We do > and all kinds of commit counters completely and use just hashes and release tags. - Release tags for versions - Hashes for precise identification of a commit and searching - Offsets for night versions
dunkaist commented 2024-04-10 22:40:38 +02:00
Owner
Copy Link

Do we need that offset at all?

Yes. We're planning 2 image variants: release (versioned) and night build, where offset will show how far this image from release

Why would we want to know 'how far this image from release'? This info is of no use. Let's say an image is 20, 200 or 2000 commits from a git tag, so what? I believe the next release should happen when all the roadmap tickets are closed. Are we going to have a roadmap ticket like 'make 100 commits'?

I have noticed that some people prefer to put unrelated changes to a single commit 'not to waste revision numbers'.

'Cuz for people revision number is not just number, but almost version.

Then maybe people should spend more time reading manuals. Because revision numbers of a repo are not distro versions at all. For example, there are quite a few files in our repo that are not in the distro. Changing many of them doesn't even trigger the autobuild. When it comes to technical matters, reading manuals really helps.

Why to increment version if you just fix TYPO?

I didn't say that.

Also, as I understood, SVN can't push multiple commits. So, why not to put some minor changes in one commit?

First of all, it takes time for other people to find out that the changes are actually unrelated. It is obvious for the author but not for others. Then, merging unrelated changes into one commit makes it harder to understand and review them. One commit of 10 files is harder to understand than 10 trivial commits. Sometimes 10 changes are spread over 3 files where each file has about 3 unrelated edits. Enjoy your time reading and reviewing. If a developer is lazy to commit unrelated changes separately, then why should other people spend their time on sorting things out and review? You are lazy and we are lasy, high five, tl;dr.

My opinion is that we should care more about readability rather than revision numbers.

v0.7.7.6+12 is pretty readable, isn't?

I meant readability of patches. By saving a few revision numbers a developer wastes time of other developers. So, what is a more important resource to save: revision numbers or developer time?

If we can keep it as short and readable as v0.7.7.6+, what is the reason to make it longer and less readable?

Because the number of revisions is unlimited unlike the number of developers and amount of their time.

Wdym? This structure should be initialized while building by script

I mean the same thing as I described above. Ten trivial commits are easier to understand than a single commit of ten files, because firstly you have to somehow find out the changes are unrelated. It takes time of developers. The larger a commit is, the less a developer wants to review it. For example, I don't see many people reviewing this PR, even though they have been asking for git for years. Partially because the kernel commit addresses several issues at once and nobody wants to bother with it.

Maybe switching to git is a great moment to drop revision numbers

We do

and all kinds of commit counters completely and use just hashes and release tags.

  • Release tags for versions
  • Hashes for precise identification of a commit and searching
  • Offsets for night versions

Why can't we use hashes for nightbuilds too? Why to introduce yet another entity of a tag offset?

> > Do we need that offset at all? > > Yes. We're planning 2 image variants: release (versioned) and night build, where offset will show how far this image from release Why would we want to know 'how far this image from release'? This info is of no use. Let's say an image is 20, 200 or 2000 commits from a git tag, so what? I believe the next release should happen when all the roadmap tickets are closed. Are we going to have a roadmap ticket like 'make 100 commits'? > > I have noticed that some people prefer to put unrelated changes to a single commit 'not to waste revision numbers'. > > 'Cuz for people revision number is not just number, but almost version. Then maybe people should spend more time reading manuals. Because revision numbers of a repo are not distro versions at all. For example, there are quite a few files in our repo that are not in the distro. Changing many of them doesn't even trigger the autobuild. When it comes to technical matters, reading manuals really helps. > Why to increment version if you just fix TYPO? I didn't say that. > Also, as I understood, SVN can't push multiple commits. So, why not to put some minor changes in one commit? First of all, it takes time for other people to find out that the changes are actually unrelated. It is obvious for the author but not for others. Then, merging unrelated changes into one commit makes it harder to understand and review them. One commit of 10 files is harder to understand than 10 trivial commits. Sometimes 10 changes are spread over 3 files where each file has about 3 unrelated edits. Enjoy your time reading and reviewing. If a developer is lazy to commit unrelated changes separately, then why should other people spend their time on sorting things out and review? You are lazy and we are lasy, high five, tl;dr. > > My opinion is that we should care more about readability rather than revision numbers. > > `v0.7.7.6+12` is pretty readable, isn't? I meant readability of patches. By saving a few revision numbers a developer wastes time of other developers. So, what is a more important resource to save: revision numbers or developer time? If we can keep it as short and readable as v0.7.7.6+, what is the reason to make it longer and less readable? > > Because the number of revisions is unlimited unlike the number of developers and amount of their time. > > Wdym? This structure should be initialized while building by script I mean the same thing as I described above. Ten trivial commits are easier to understand than a single commit of ten files, because firstly you have to somehow find out the changes are unrelated. It takes time of developers. The larger a commit is, the less a developer wants to review it. For example, I don't see many people reviewing this PR, even though they have been asking for git for years. Partially because the kernel commit addresses several issues at once and nobody wants to bother with it. > > Maybe switching to git is a great moment to drop revision numbers > > We do > > > and all kinds of commit counters completely and use just hashes and release tags. > > - Release tags for versions > - Hashes for precise identification of a commit and searching > - Offsets for night versions Why can't we use hashes for nightbuilds too? Why to introduce yet another entity of a tag offset?
dunkaist commented 2024-04-10 17:34:55 +02:00
Owner
Copy Link

Can we start using semver for kernel ABI versioning and keep our current scheme for distros? Like Windows 7 had its kernel version 6.1, Windows 8 had kernel 6.2, Windows Server 2012 had 6.3, Red Hat Enterprise Linux 9.0 had the kernel of version 5.14.

I believe this could be the answer. Thus we can both track the kernel ABI properly and to allow significant userspace updates to significantly update the distro version.

Can we start using semver for kernel ABI versioning and keep our current scheme for distros? Like Windows 7 had its kernel version 6.1, Windows 8 had kernel 6.2, Windows Server 2012 had 6.3, Red Hat Enterprise Linux 9.0 had the kernel of version 5.14. I believe this could be the answer. Thus we can both track the kernel ABI properly and to allow significant userspace updates to significantly update the distro version.
dunkaist requested review from dunkaist 2024-04-10 17:35:50 +02:00
dunkaist reviewed 2024-04-10 22:54:18 +02:00
data/Tupfile.lua
@ -875,2 +875,2 @@
then str='$(LANG=ru_RU.utf8 date -u +"[автосборка %d %b %Y %R, r$(get-current-revision)]"|iconv -f utf8 -t cp866)'
else str='$(date -u +"[auto-build %d %b %Y %R, r$(get-current-revision)]")'
then str='$(LANG=ru_RU.utf8 date -u +"[автосборка %d %b %Y %R, g$(git rev-parse --short HEAD)]"|iconv -f utf8 -t cp866)'
else str='$(date -u +"[autobuild %d %b %Y %R, g$(git rev-parse --short HEAD)]")'
dunkaist commented 2024-04-10 22:54:18 +02:00
Owner
Copy Link

We are having a hard time switching from svn to git now. This is partially because of svn features that git lacks, e.g. svn-keywords. Maybe we shouldn't repeat our mistakes and hardcode git specific commands now. If get-current-revision is an external command to get an svn revision number, let's use something like get-current-commit-hash for git. Or, even better, get-current-commit-id. The last one looks even more VCS-neutral, i.e. future-proof.

We are having a hard time switching from svn to git now. This is partially because of svn features that git lacks, e.g. svn-keywords. Maybe we shouldn't repeat our mistakes and hardcode git specific commands now. If get-current-revision is an external command to get an svn revision number, let's use something like get-current-commit-hash for git. Or, even better, get-current-commit-id. The last one looks even more VCS-neutral, i.e. future-proof.
ace-dent commented 2024-05-16 22:14:18 +02:00
Member
Copy Link

Hi @mxlgv @dunkaist @Sweetbread.
Has this PR stalled?

I think version (a human sanctioned release) should be separated from build numbering (automated).
So we should manually tag a release (e.g. with semver 0.7.7). This is then an 'official' release. The argument by @dunkaist that we might cycle through major revision very fast with lots of breaking changes, can be mitigated if we do a batch of breaking changes and wait before cutting that release. (i.e. 0.7.7+xxx might have breaking changes for testing, but is not an official release, until tagged as 1.0.0, etc.)

Nightly / dev builds should be differentiated by suffixing with the shortened commit hash.
So it could be: 0.7.7 098ac2f. There are tools in git to check the short hash is unique.

I appreciate the argument about sequential build numbering for bisecting any regressions. (Having done a lot of QA in the past). But I think using a build image's date + time is sufficient for these rare instances. However, you get this sequential number for 'free' using the current suggestion: git describe --tag --long.

So in short, I think it's worth trying the proposal.
What are the next steps?

Hi @mxlgv @dunkaist @Sweetbread. Has this PR stalled? I think version (a human sanctioned release) should be separated from build numbering (automated). So we should manually `tag` a release (e.g. with semver 0.7.7). This is then an 'official' release. The argument by @dunkaist that we might cycle through major revision very fast with lots of breaking changes, can be mitigated if we do a batch of breaking changes and wait before cutting that release. (i.e. 0.7.7+xxx might have breaking changes for testing, but is not an _official_ release, until tagged as 1.0.0, etc.) Nightly / dev builds should be differentiated by suffixing with the shortened commit hash. So it could be: 0.7.7 098ac2f. There are tools in git to check the short hash is unique. I appreciate the argument about sequential build numbering for bisecting any regressions. (Having done a lot of QA in the past). But I think using a build image's date + time is sufficient for these rare instances. However, you get this sequential number for 'free' using the current suggestion: `git describe --tag --long`. So in short, I think it's worth trying the proposal. What are the next steps?
Sweetbread closed this pull request 2024-06-05 23:06:53 +02:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
rgimad
dunkaist
Labels
Clear labels   
C

   
Category/Applications

   
Category/Drivers

   
Category/General

   
Category/Kernel

   
Category/Libraries

   
Eolite

   
FASM

   
FS

   
HLL

   
Influence/Settings

   
Influence/Text/TYPO

   
IRCC

   
Kernel
  
Kind
Breaking
Breaking change that won't be backward compatible

  
Kind
Bug
Something is not working

  
Kind
Build

  
Kind
Documentation
Documentation changes

  
Kind
Enhancement
Improve existing functionality

  
Kind
Feature
New functionality

  
Kind
Security
This is security issue

  
Kind
Testing
Issue or pull request related to testing

  
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Medium
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

No Label
C
Category/Applications
Category/Drivers
Category/General
Category/Kernel
Category/Libraries
Eolite
FASM
FS
HLL
Influence/Settings
Influence/Text/TYPO
IRCC
Kernel
Kind
Breaking
Kind
Bug
Kind
Build
Kind
Documentation
Kind
Enhancement
Kind
Feature
Kind
Security
Kind
Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: KolibriOS/kolibrios#62
No description provided.
Delete Branch "change-get-version-api"

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?