[Nix-dev] RFC: NixOS version string format

[Bjørn Forsman]

On 1 May 2014 15:26, Eelco Dolstra <eelco.dolstra at logicblox.com> wrote:
> Hi,
>
> On 01/05/14 15:15, Bjørn Forsman wrote:
>
>>
>> I think the reason I want this is the same reason we have version
>> numbers in the first place; because it's easier for humans (me!) to
>> use/remember. Knowing that it's 18 commits after 14.04 is easier to
>> relate to than that it's 42698 commits since the very beginning. Also,
>> the current scheme looks a lot like MAJOR.MINOR.PATCH, but it doesn't
>> act like it: PATCH is never reset to zero, unlike other projects I've
>> seen. So it feels a bit odd to me. (Personal opinion, I agree!)
>
> I agree that having the number of commits since the start of the branch is
> nicer. I've just made a change that does this. The only problem is that it
> causes the version number in the 14.04 branch to jump backwards this once, but
> since we're not using it for anything automated, it shouldn't be a big problem.

Awesome! Thanks!

>> Made up example from an alternative (near future?) nixos world:
>>
>> $ nixos-version
>> 14.04-18-gabcd1234
>> $ cd nixpkgs
>> $ git describe
>> 14.04-20-gdefg5678   # Ah, my checkout is two commits ahead!
>
> That's assuming you're on the 14.04 branch. If you're on master, and 14.04 is
> the nearest tag, it will say something similar, but it will be misleading
> because they're not the same commits.

Right. The number of commits since a tag is not unique, because of
branching. That's why the hash is there at the end.

To complicate further, if the release tag is made on the release
branch and is not reachable from master, I don't think "git describe"
on master will find that tag at all.

I think there are two alternative ways to deal with this. Either wait
with creating the release branch until a release tag has been made on
master. Or create the release branch, create a release tag on that
branch and merge the release branch back into master. Using either of
these two methods, the released tag will be visible in both branches
from there on, and "git describe" should give meaningful output.

Best regards,
Bjørn Forsman