Hi Ludo,

ludo@gnu.org (Ludovic Courtès) writes:

> Chris Marusich <cmmarusich@gmail.com> skribis:
>
>> At the moment, I only have this to add: It would be nice if we could
>> decide on how we will use version numbers going forward and publish a
>> description of that in the manual or on the website.
>>
>> I think the important thing is that we publish a description.  The
>> details of it are less important.  We can use Semantic Versioning [1],
>> Sentimental Versioning [2], or something totally different.  As long as
>> we publish our decision and stick to it, everyone will know what to
>> expect.
>
> Good point!  The difficulty here is that Guix is effectively a large
> collection of libraries, which makes it hard to map it to the semver
> story, I think.  Or to put it differently, we should map to semver in an
> “abstract way”: what semver refers to as “API changes” would rather be
> important CLI/API changes.
>
> Thoughts?

I spoke of version numbers, but what I really meant to say is that for
1.0 and beyond we should clearly set expectations regarding stability.
By properly setting expectations, we can avoid surprises and improve the
experience for people using Guix, especially people trying Guix for the
first time.  The version number scheme is just one aspect of that.

I'm not advocating that we change anything; I'm only advocating that we
should make our stability promise (if any) clear by documenting it.  If
you want to know my thoughts about what sort of stability promise we
should provide, I'd be happy to talk about that also, but here I'm only
saying that we should provide a promise.  The details of the promise are
less important.

If you agree, then perhaps we can proceed along the following lines:

1) Discuss what our stability promise should be.  It might be that we
   decide to simply stick with the status quo and document it.  But
   whatever the result, it should be something that hopefully everyone
   agrees on (especially maintainers and contributors).

2) Document it.  Put it on the website, in the manual, etc.

3) Follow it.  Mention it in the Contributing section of the manual, the
   README, etc., and require people to adhere to it when making changes.

As a maintainer, what do you think?  Does it makes sense for the Guix
project to set expectations by documenting our stability promise?

-- 
Chris