On the quest for a new release model (was: Discussion notes on releases and branches)

[Cayetano Santos <csantosb@inventati.org>]

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]


Hi Guix,

Let me spin off last year thread on releases (flavored by an external to
the project point of view), with the goal to relaunch the debate on
releases.

Disclaimer: the rolling release model is great and more than enough for
me, and teams constitute an mportant step forward.

Disclaimer 2: guix-system is probably great, but using guix as a foreign
package manager is absolutely paramount, and would open the door to all
things guix, bringing lots of new users/contributors.

Now, any user in the world may install guix and upgrade to latest
version, sure. But.

First, for the current needs:

- distributions privilege and package guix releases (alpine, debian,
- arch, etc.), as guix itself does
- 1.4.0 dates back from 2 years ago
- in my experience, people tend to give guix a try, check obsolete sw,
  just give up, no matter the remaining advantages
- remote ci/cd images need to refer to a release for traceability
- apt-get install guix (1.4.0) && guix pull is a painful experience

Additionally, releases makes people talk about guix, give an overall
positive impression of the community, and are a good argument (and
publicity !) in favor of using it (unfortunate, but that’s the way it
goes). See emacs devel cycle, for example.

Now, for (a very naif) proposal (from a non contributor).

- simver[1] is the way to go
- devel as the branch for developments, master for releases and
  security/bug fixes
- major should follow core merges to devel
- minor should follow non-core teams merges
- patch fixes are backported to master

Yes, you guess [2] it.

Please, consider all the previous as an excuse to motivate the need for
releases, not as serious guidelines (I’m not the right person for that.)
For what I see around me, guix could easily be used by a larger audience
(foreign first, system then). Releases are a real requirement to that
goal.

Best,

[1] https://semver.org/
[2] https://nvie.com/posts/a-successful-git-branching-model/

--
Cayetano Santos
GnuPG Key:   https://meta.sr.ht/~csantosb.pgp
FingerPrint: CCB8 1842 F9D7 058E CD67 377A BF5C DF4D F6BF 6682

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 259 bytes --]