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>
Cheers, -- Guido
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+byzN
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-2pureosN
for byzantium¹ and
1.0-2pureosN~amberM
for amber (when backporting the byzantium version to amber).
Does that make sense? Cheers, -- Guido
1) according to https://tracker.pureos.net/w/development/packaging_overview/
Cheers, -- Guido
On Mon, 2020-12-07 at 16:15 +0100, Guido Günther wrote:
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+byzN
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-2pureosN
for byzantium¹ and
1.0-2pureosN~amberM
for amber (when backporting the byzantium version to amber).
Does that make sense?
I think it does make sense Guido. I ought to have replied sooner, but I don't think that there's much I can add to the discussion since I think this follows our versioning scheme as documented. In fact I'm going to add this information to that document unless Matthias has any objections.
Regards,
Jeremiah
Cheers, -- Guido
- according to
https://tracker.pureos.net/w/development/packaging_overview/
Cheers, -- Guido
PureOS-project mailing list PureOS-project@lists.puri.sm https://lists.puri.sm/listinfo/pureos-project
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+byzN
I 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-2pureosN
for byzantium¹ and
1.0-2pureosN~amberM
for 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 :-)
Cheers, Matthias
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+byzN
I 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-2pureosN
for byzantium¹ and
1.0-2pureosN~amberM
for 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/