On Monday, November 10, 2025 8:00:01 AM Mountain Standard Time Jérémy Lal wrote: > Le lun. 10 nov. 2025 à 15:06, Simon Richter <sjr@debian.org> a écrit : > > Hi, > > > > On 11/10/25 22:15, Jérémy Lal wrote: > > > However, upstream quickjs-ng version is 0.11.0, but current quickjs > > > debian version is 2025.04.26-1. > > > > > > Policy 5.6.12 requires to ask here the question: > > > is it okay to use an epoch 1:0.11.0-1 in that case ? > > > > Are you replacing the main package, or are you providing an alternate > > package (quickjs-ng) that generates a transitional package, and no > > further versions of the old package will be uploaded? > > Replacing the main package. > The old package is only used by edbrowse (reverse build-dep on libquickjs), > and we are already working on it (upstream update added support for > quickjs-ng). > > In the latter case, it is also possible to give that transitional > > > package a version number like "2025.99+really0.11.0" -- a source package > > can build binaries with different version numbers. > > Yes, good idea. And that should also work with upgrading quickjs "in-place". > > > The other question is whether this is a drop-in replacement, or if it > > should really be named "quickjs-ng", and dependencies adjusted, with no > > transition managed through packages. > > It's not a drop-in replacement, though there are more and more packages > switching to quickjs-ng. > Porting can be easy in the simplest cases... My personal preference would be to create a new package, so that the source and binary package names clearly specify that this is quickjs-ng instead of the older quickjs. -- Soren Stoutner soren@debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part.