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.
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…
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…
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 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 commits counters completely and use just hashes and release tags.
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…
dunkaist/kolibrios.org to KolibriOS/kolibrios.org
dunkaist/kolibrios to KolibriOS/kolibrios