hi devs,

last week Alex and I talked about shorter nano release cycles and thus shorter cycles of declaring code as stable.

Currently, there is no automation and mostly I urge ourselves to declare code as stable. Some projects are actually releasable but do not get released as they get forgotten (e.g. the PXE project x2gothinclient.git).

What Alex and I came up with and what I would like to shorly discuss here is a more automated, but still humanly triggered mechanism.

The version number of Git projects in X2go Git that

  (a) are usable
  (b) are not obviously broken/buggy/instable
  (c) have not been worked on for 2 weeks
  (d) have been tested (at least by me and somebody else)

will get incremented in the last digit (1.2.3.x -> 1.2.3.y) after these two weeks, packages will be declared as stable and provided in the corresponding repositories.

The shorter release intervals will allow us to keep a better track of the milestones within the projects we have made. I partly consider this as a facility of documentation (that is: documenting usable states of the code).

Discussion+feedback welcome,
Mike

PS:

The first release day can already be tomorrow:

  x2gothinclient
  x2goclient
  cups-x2go

A week from tomorrow:

  x2goserver
  x2gognomebindings
  x2golxdebindings
  x2goagent (bug fix release currently being prepared by Alex)
  nxcomp
  nxcompext
  nxcompshad
  nxproxy


--

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: [email protected], http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

Attachment: pgpkNibr5ilQ5.pgp
Description: Digitale PGP-Unterschrift

_______________________________________________
X2go-Dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/x2go-dev

Reply via email to