Hi, On Tue, Dec 08, 2020 at 02:45:07AM +0100, Matthias Klumpp wrote:
Am Mo., 7. Dez. 2020 um 16:16 Uhr schrieb Guido Günther agx@sigxcpu.org:
Hi, On Fri, Dec 04, 2020 at 02:37:57PM +0100, Guido Günther wrote:
Hi, since we're dropping phone specific package for byzantium we also ought to drop `+librem5.X' in the version numbers. Matthias, what would you suggest here so that we generate higher version numbers in byzantium when backporting a package to both amber and byzantium to be consistent whith the rest of PureOS but also have a higher number than the current
<upstream>-<debian-rev)pureos+librem5.<revision>For the time being addin `+byzN` at the end of the version number will do:
1.0-2pureos+librem5+byzNI think that's an okay-ish temporary workaround - unfortunately 1.0-2pureos1 isn't considered a higher version than 1.0-2pureos+librem5, so I see no other way to do this transition.
For new upstream versions we can drop the librem5 postfix since there's no difference between laptop and phone and we can do
1.0-2pureosNfor byzantium¹ and
1.0-2pureosN~amberMfor amber (when backporting the byzantium version to amber).
Does that make sense? Cheers, -- Guido
Yes, that's exactly how this should look like, I think - the phone packages wouldn't be treated any differently than regular PureOS packages, going forward. Makes a lot of sense to me :-)
Thanks. Just to clarify since i got questions regarding that:
We want to use
1.0-2pureosN~amberM
even when we don't upload 1.0-2pureosN to byzantium right away since otherwise *if* we upload to byzantium later on we're in version trouble again. So basically i expect all uploads that don't go to landing to have a `pureosN~<suite>M`. Right?
Also we use `~amberM` even for `amber-phone` to keep the length of the version number somewhat under control (and there's little conflict potential and the additional '-' confuses even more).
Cheers, -- Guido
Cheers, Matthias
-- I welcome VSRE emails. See http://vsre.info/