From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Roadmap for =?utf-8?Q?Guix=C2=A01=2E0?= Date: Sun, 19 Aug 2018 18:12:38 -0700 Message-ID: <87lg91on7d.fsf@gmail.com> References: <878t5udq9u.fsf@gnu.org> <871sbls435.fsf@gmail.com> <87tvnqipal.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35194) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frYkY-0002Oj-6e for guix-devel@gnu.org; Sun, 19 Aug 2018 21:12:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1frYkV-00018Z-4g for guix-devel@gnu.org; Sun, 19 Aug 2018 21:12:54 -0400 In-Reply-To: <87tvnqipal.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 19 Aug 2018 13:11:46 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludo, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Chris Marusich 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 > =E2=80=9Cabstract way=E2=80=9D: what semver refers to as =E2=80=9CAPI cha= nges=E2=80=9D 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? =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlt6FYYACgkQ3UCaFdgi Rp3ieBAAt13VO/4aY9hf+5qWwBcxyfI7mgkecIwZJNQPdfGA8ttX5BxHFXatNM8g OvbjjoBG5DLUDQxGXwo0y9qgMEkRlUFF8Rjh1AFjKi30eLR+5lVDbuXl6fIEHb2D YoR3kpSxdtYRDdPJ+u8cD9tP6pHaKdUBEuSZ/PS39HhUrHTkst+HN8CdZxsNXY9x JyAeCf5RLZnLxbd4SIR7a7xO7Zf2vbdkaQ1cvIgUhI6H1++TKXIJqZOKNINgnQBc MVq577rRch0jMIp2FxglDmtMAKwfquoGQLN+bpXJJwJm/fV/UuKSHlLDdSS3Q+uG +o43MkpYhLadaDzGLhZ+yCEeWMg+xZ9Ptsh/SwhgeAi6LxPMBg/RKh5rmIsM56Vt Jh7pEiGb00mENgJBcyndwYBySXbSE5eZHauxpwx0e8wd8zHWUgKN/2ErQ8nYh3aK vEYIOHk5IkAYpyTTxa1r5Kx55XOXALygZvZF2wNUCcgWd+GW2bly1w/m58q/A3iC nztY5RiJKPJTVH767wLuVetzWUAwyJpFwu0HrbM/DJ5EVbTfupDwOPP5gcydK/e6 gTWKayBpxb38Cazgl6FQbvf2vrL+GFfKMAaCfQc9w20jk1/eu3X8tHfpbW7PYnuk WiqixJCwDJxUR7ErDipTyOVZmNwBQ6FUvZgWHT4RaqaDrcSMCg4= =TVjO -----END PGP SIGNATURE----- --=-=-=--