On Fri, Oct 21, 2022 at 3:41 PM Heiko Becker <[email protected]> wrote: > > On Friday, 21 October 2022 11:44:12 CEST, Harald Sitter wrote: > > On Fri, Oct 21, 2022 at 10:52 AM Antonio Rojas <[email protected]> wrote: > >> Hi, > >> ... > > > > plasma-workspace-1.0.0.25.tar.xz > > plasma-desktop-1.0.0.0.tar.xz > > > >> Having each project tarball have a different version number at > >> release time would make it a packaging hell. > > > > How so? You need only ever pick the highest version number. > > Wearing my distro packager hat, I can understand the concerns because to > pick the highest version you obviously need to know it. For one package > this is not that much of a problem, but for example for >= 200 packages > released with Gear it can be.
Can't we figure out the highest version relatively easily through automation? We intentionally use digit-only versions so that they can be fed into version compare mechanisms without much worry for the many styles of -rc, ~beta, .a suffixes. > Furthermore I'm a little concerned that the same last digit can stand for a > "private" and public release as well, just depending on the unrelated fact > if a respin was needed or not. I assume using something like -rcN, like > Frameworks currently do, is not that attractive because after the testing > phase all final tarballs need to be created, even if they are identical to > the last -rc, right? Yeah, the -rcN scheme seems inappropriate with the invent workflow. I'm curious what the concern with pubic versus private is though. Isn't the workflow the same regardless? I mean, I somewhat intentionally treat them the same because the workflow I imagine is the same regardless. So, less code over all. - walk all tarballls - determine highest versions - check if highest version is packaged - if not packaged prepare a new package and propose MR (or whatever each distro does to actually land a new release) The only difference between public and private is where you land stuff, no? HS
