[debhelper-devel] Some thoughts about named compat level and version numbers

[Niels Thykier]

Axel Beckert:
> Hi,
> 

Hi,

> citing from debhelper(7):
>> [...]
> 
> Wouldn't it make sense to have a named compat level which always
> refers to the most recent recommended or stable (is there a
> difference?) level? I.e. introducing a named level "stable",
> "recommended" or "default" which now is equivalent to "10" (and would
> have been equivalent to "9" until very recently) and more or less
> corresponds to debhelper's major version...
> 

I have considered that and I am slightly conflicted on it.  Named compat
levels are a double-edged sword.  Notably, it could end up leading to
that the debhelper 11 (or N+1) upload breaking a number of packages.
Simply because people started using the named compat level for the
"stable"/"recommended" compat level.

   The "beta-tester" compat level "clearly" delegates the
   responsibility of breakage to the maintainers.

I am not entirely against it, but I think needs a lot more careful
design than the "beta-tester" one.

Personally though, I am inclined to see how well this feature is adopted
before investing a lot of time.

> Apropos version numbers: I'd be very happy it if debhelper would go
> back to a major.minor.micro (aka break.feature.bugfix) syntax (i.e.
> more or less semantic versioning[1]) instead of the (IMHO ugly and
> unreadable) date-based minor versions which we had during most of the
> 9.x releases.
> 
> 		Regards, Axel
> 

Ok, noted.  You are not the first to suggest a different version scheme
for debhelper after the 9.<DATE> series. :) Personally, I am inclined to
go with 10.X[.Y] if only because <DATE> does not interact all that well
with "dch -i".

Thanks,
~Niels