Dear Maintainer,

could we have a definitive documentation of debian versionning including corner
case
- the +really scheme should be documented with better discussion than policy
- the +~ multiple tarball, and uscan checksum should be documented. I have implemented this and I can explain why +~
- the +deb12u1 scheme for security release should be documented, including the
~deb12u1 in case of backport.
We have in archive some +deb12u1~debu11u1 backport and it should be documented
somewhere.
- note that we should offer a preview suffix for instance for testing under
salsa. Some user used +deb12u1~1
but it is not safe against +deb12u1~debu11u1 upgrade for instance. So a suffix
like ~pre should be used, and should be documented

Bastien

Maybe we could set aside "~~~" for such uses.  ~pre is not going to be foolproof.

I am *very* happy that ~deb sorts later than ~bpo, as that updates a backport to a stable / oldstable / oldoldstable update.  But that was sheer luck.  This is not true for ~pre, but would work for ~~pre or ~~~~whatever...

Le lundi 12 août 2024, 00:04:15 UTC Henrique de Moraes Holschuh a écrit :
You mean ~+~pre ? because +deb12u1~~~ is before +deb12u1~debu11u1 and we want to upgrade to deb12u1~debu11u1 to deb12u1~+~pre1 to  +deb12u1

Yes sheer luck do +~+pre will do the trik and be safe against +~ck of javascript

Hello,

Policy has a fair bit of this already but it's spread out.
E.g. take a look at 5.6.12.2.

Rather than duplicating, it might be helpful to have a discussion in
dev-ref that is kind of an index to all these relevant bits of Policy.

Le mardi 13 août 2024, 03:03:31 UTC Sean Whitton a écrit :
Yes I think so, except they are some stuff not in policy:
- javascript and checksum that is in uscan
- the backport of security release that is an interpretation of policy
- the preview release

I believe that policy is like law and devref is some kind of circulaire in civil law country
(https://en.wikipedia.org/wiki/Circulaire)  an interpretation of a legal text that do not
introduce new rules but clarify law.

rouca

I agree on what you wrote about policy hence many years ago I made
piuparts.debian.org prominently display liw's piuparts slogan: Policy is your
friend. Trust the Policy. Love the Policy. Obey the Policy.

I disagree however that dev-ref is really the same as a Circulaire. Sometimes
this might be the case, but sometimes also not. dev-ref can be a link collection,
can point or include best practices, can list more than one way to do it etc.
to put it dffierently: dev-ref is not about whether something is legal, but whether
it's sensible to do.

El 12/08/24 a las 00:15, Bastien Roucariès escribió:

The corner(*) case you are describing is: there is a preview package
available via salsa ci/aptly job or whatever; we want a bullseye user to
avoid upgrading to that preview package, while still being able to
upgrade to the actual bookworm package. Please, tell me if that doesn't
match your thoughts.

The broader question is how we *should* version an in-development
package. Myself, I tend to avoid using the final version in the VCS
until I release, to avoid creating any confusion for anyone looking at
the repo (or if I make the build artifacts available via aptly). So I
use gbp dch -S that creates a snapshot debian/changelog with a suffix
~N.gbpCOMMIT_ID, but that is not safe for the corner case you describe.

(*) and this is a very corner case. We are talking about PPA-like
repositories that only informed users would enable. But let's try to be
in the safest possible place anyway.

~+N... (where N is [0...)) would do the trick?

Le mercredi 14 août 2024, 13:42:29 UTC Santiago Ruano Rincón a écrit :

~+~ is safe and look like a smiley throwed upon (memotechnic)

Note the at the contrary

+~+ will be perfect for user recompiled package

So they are some sense on it.

I prefer here be on the safe side