[opensuse-buildservice] How to manage a product with very frequent releases and no maintenance for each release
Hi everyone, In this case we are talking about Uyuni (systemsmanagement:Uyuni), the new upstream for SUSE Manager (replacing spacewalk). We basically want to release each two/four/six weeks a new version, starting with 4.0, promoting packages from systemsmanagement:Uyuni:Master (development project) to some place. Between one version and the other, there will be no maintenance. Each change, whatever itis, will required a new release and version. You could see it as Tumbleweed to some extent, but with a big difference: we really want to have versions, as Leap or SLE, but unlike Leap or SLE, very frequent releases. This is useful, for example, if users are running a version of Uyuni in "production", we release a new version, and they want to setup a server with the same version as "production" and then test migration. One way I see to do this would be creating a systemmanagement:Uyuni subproject for each version and then freeze the packages (so we would have systemsmanagement:Uyuni:4.0, systemsmanagement:Uyuni:4.1, systemsmanagement:Uyuni:4.2 and so on...) However I wonder if this is the correct way to do it, because to me it seems a little bit overkill. Other option, of course, would be just storing the zypper repositories outside OBS/download.opensuse.org (there would be a set of repositories for each version), but I don't like the idea. I was reviewing how other products are working, but could not find any that uses this approach. Basically either they have versions with maintenance (:Update subproject), either they follow Tumbleweed approach, where the product itself is not versioned. So, has anyone in the list experience about how to achieve this with OBS? Thanks! -- Julio González Gil <jgonzalez@suse.com> Release Engineer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
Hey, On 06.09.2018 16:33, Julio González Gil wrote:
So, has anyone in the list experience about how to achieve this with OBS?
The OBS project has a rolling release (our git master) -> OBS:Server:Unstable We have per major version (2.X) a project -> OBS:Server:2.9 or OBS:Server:2.8 Additionally we use a simple staging process -> OBS:Server:2.9:Staging Minor versions (2.9.X) are released as updates in the major version projects. https://github.com/openSUSE/open-build-service/wiki/build.o.o-Projects
One way I see to do this would be creating a systemmanagement:Uyuni subproject for each version and then freeze the packages... However I wonder if this is the correct way to do it, because to me it seems a little bit overkill.
Because? Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On jueves, 6 de septiembre de 2018 17:12:25 (CEST) Henne Vogelsang wrote:
On 06.09.2018 16:33, Julio González Gil wrote:
So, has anyone in the list experience about how to achieve this with OBS?
The OBS project has a rolling release (our git master) -> OBS:Server:Unstable
We have per major version (2.X) a project -> OBS:Server:2.9 or OBS:Server:2.8
Additionally we use a simple staging process -> OBS:Server:2.9:Staging
Minor versions (2.9.X) are released as updates in the major version projects.
Yes, I noticed. In this case we will not have minor versions.
https://github.com/openSUSE/open-build-service/wiki/build.o.o-Projects
One way I see to do this would be creating a systemmanagement:Uyuni subproject for each version and then freeze the packages... However I wonder if this is the correct way to do it, because to me it seems a little bit overkill.
Because?
Well, keeping in mind that we release the so called "client tools" for each distribution and distribution version managed by Uyuni, that means creating a new project with the subprojects for each new version each 2/4/6 weeks with all the metadata and prjconf and them submit every package there. I am not even sure if OBS administrators would be happy if we generate 24 projects (or even more per year). Creating zypper repos and copy the contents from the FTP generated repos for systemsmanagement:Uyuni:Master could be easier, but I guess that automating all the OBS stuff I described above should be doable as well. -- Julio González Gil <jgonzalez@suse.com> Release Engineer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
On Thu, Sep 6, 2018 at 10:34 AM Julio González Gil <jgonzalez@suse.com> wrote:
Hi everyone,
In this case we are talking about Uyuni (systemsmanagement:Uyuni), the new upstream for SUSE Manager (replacing spacewalk).
We basically want to release each two/four/six weeks a new version, starting with 4.0, promoting packages from systemsmanagement:Uyuni:Master (development project) to some place.
Between one version and the other, there will be no maintenance. Each change, whatever itis, will required a new release and version.
You could see it as Tumbleweed to some extent, but with a big difference: we really want to have versions, as Leap or SLE, but unlike Leap or SLE, very frequent releases.
This is useful, for example, if users are running a version of Uyuni in "production", we release a new version, and they want to setup a server with the same version as "production" and then test migration.
One way I see to do this would be creating a systemmanagement:Uyuni subproject for each version and then freeze the packages (so we would have systemsmanagement:Uyuni:4.0, systemsmanagement:Uyuni:4.1, systemsmanagement:Uyuni:4.2 and so on...)
However I wonder if this is the correct way to do it, because to me it seems a little bit overkill.
Two questions to ask here: 1. Is the intent to only maintain a single release series? If yes, do you intend for seamless migration/upgrade to be possible? 2. If you don't intend to maintain a single release series, do you intend to maintain branches mapping to each release series? -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On jueves, 6 de septiembre de 2018 17:34:58 (CEST) Neal Gompa wrote:
On Thu, Sep 6, 2018 at 10:34 AM Julio González Gil <jgonzalez@suse.com> Two questions to ask here:
1. Is the intent to only maintain a single release series? If yes, do you intend for seamless migration/upgrade to be possible?
This is more a question for Uyuni-devel, but the list is still not created, so I will give a short answer here: We will not be doing maintenance of any version, the idea is having a rolling release system (but with numbered versions, unlike Tumbleweed which doesn't have numbering for the system itself AFAIK). We intend to have migration paths and make the migration seamless as long as the base system is not changed. In those cases where the base system changes (i.e. Leap 42.3 to Leap 15.0), there could be a special procedure to migrate, but it's yet to be defined. I will forward details to the uyuni-devel list as soon as I have all of them and the list is ready. -- Julio González Gil <jgonzalez@suse.com> Release Engineer SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
On Donnerstag, 6. September 2018, 18:24:56 CEST wrote Julio González Gil:
On jueves, 6 de septiembre de 2018 17:34:58 (CEST) Neal Gompa wrote:
On Thu, Sep 6, 2018 at 10:34 AM Julio González Gil <jgonzalez@suse.com> Two questions to ask here:
1. Is the intent to only maintain a single release series? If yes, do you intend for seamless migration/upgrade to be possible?
This is more a question for Uyuni-devel, but the list is still not created, so I will give a short answer here:
We will not be doing maintenance of any version, the idea is having a rolling release system (but with numbered versions, unlike Tumbleweed which doesn't have numbering for the system itself AFAIK).
We intend to have migration paths and make the migration seamless as long as the base system is not changed.
In those cases where the base system changes (i.e. Leap 42.3 to Leap 15.0), there could be a special procedure to migrate, but it's yet to be defined.
what you need to decide is which versions you want to keep available. If you have just one source revision you want to offer (even when maybe build against multiple base distros) a single project is enough. People would get updates from there automatically without any change. A Staging project for testing might be a good idea then... If you want to keep certain releases and these repositories should not change you can just use the release mechanism and copy sources & binaries to a new project/repo on each release from your devel project. But your users would need to change repositories then. If you want to support minor/patchlevel updates the OBS:Server:X.Y setup is a good idea. So your users need to change repositories only for major updates. If you want to keep old binaries in the same repository to offer users to downgrade, the classic distribution maintenance scheme is the right way. Your users get latest version automatically, but can downgrade without touching the repository config. -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Julio González Gil wrote:
We basically want to release each two/four/six weeks a new version, starting with 4.0, promoting packages from systemsmanagement:Uyuni:Master (development project) to some place.
Check the :ToTest mechanism of Factory.
Between one version and the other, there will be no maintenance. Each change, whatever itis, will required a new release and version.
You could see it as Tumbleweed to some extent, but with a big difference: we really want to have versions, as Leap or SLE, but unlike Leap or SLE, very frequent releases.
Tumbleweed does have an integer number as version that can be displayed as date. Just not coded into the project name in OBS. By default OBS only publishes the last version of the repo to download.o.o. There is work in progress to keep some previous snapshots around though: http://release-tools.opensuse.org/2018/02/26/Tumbleweed-snapshot-review-site... cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (5)
-
Adrian Schröter -
Henne Vogelsang -
Julio González Gil -
Ludwig Nussel -
Neal Gompa