Mailinglist Archive: opensuse-buildservice (65 mails)

< Previous Next >
Re: [opensuse-buildservice] How to manage a product with very frequent releases and no maintenance for each release
  • From: Neal Gompa <ngompa13@xxxxxxxxx>
  • Date: Mon, 10 Sep 2018 12:16:20 -0400
  • Message-id: <>
On Mon, Sep 10, 2018 at 12:13 PM Adrian Schröter <adrian@xxxxxxx> wrote:

On Montag, 10. September 2018, 17:22:14 CEST wrote Julio González Gil:
On lunes, 10 de septiembre de 2018 17:18:07 (CEST) Neal Gompa wrote:
On Mon, Sep 10, 2018 at 10:29 AM Ludwig Nussel <ludwig.nussel@xxxxxxx>
What I wanted to say is that instead of jumping through hoops
creating subprojects etc (where users would have to change their repos),
just stick with the one project approach. If historic repo versions turn
out to be really needed, OBS should implement means for that.

This would actually be really helpful for what I do for our internal
OBS. It's been a sticking point that we don't have a way to flag in
prjconf or meta that repo publishing should be multiversioned (for
RPMs and DEBs).

The subprojects would be only as a way of storing old versions, in case
somebody needs, for example, to test migration starting from a new server.

But of course our idea is that a regular user would be able to upgrade by
running "zypper up" + the regular steps we already have for SUSE Manager,
a static repository from a static project (let's say
systemsmanagement:Uyuni:Stable or something similar).

so just keeping N versions or build results for X days would be enough?

N versions based on committed sources, with maybe also a fade-out (by
X days) for old versions in repos.

This would be especially useful for us for "CI projects", where we
want to push something and keep latest-N as well as maybe latest-N for
X days to give people an opportunity to test.

真実はいつも一つ!/ Always, there's only one truth!
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >