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

[Axel Beckert]

Hi Niels,

Niels Thykier wrote:
> > 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.

Indeed, I'm aware of potential drawbacks of that idea. That's why I'd
like to see it discussed. :-)

> 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.

Yes, that's what I had in mind as drawback, too, except that I didn't
have an explicit example in mind.

My motiviation is mostly teams maintaining a huge bunch of packages
working all mostly the same way (namely the Debian Perl Team). So
instead of bumping the compat version every time lintian complains
about not being the "recommended" version, they would put in "stable"
and then just fix those packages properly which fail.

I though must admit, that I have no idea if really that much packages
would continue to build properly or if the fallout would be more work
than a mass-commit over a few thousand packages. Nor have I talked
with the rest of the team about it. But the thought came, because I
saw one big mass-commit before us, switching all packages in git to
compat level 10 as soon as lintian argues about compat level 9 being
used.

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

Indeed. But at least I would have expected that in the suggested case,
too. But then again I see that not everybody would think that way.

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

Granted.

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

Good point. Using "beta-tester" to see if it might make sense to offer
further named comapt levels (maybe even "lowest-supported" ;-) sounds
like a good plan.

Thanks for sharing your thoughts on that topic.

> > 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.
> 
> 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".

Hehe.

While semantic versioning (http://semver.org/) has a very explicit
idea of what the major version should declare, I would say that
debhelper needs a slightly different semantic, maybe this:

major = highest released compat level
minor = new features added
micro = bugfixes

Or maybe even more closer to semver.org:

supermajor = highest released compat level
major = breaking changes (they seem to happen occassionally inside a
        compat level, too)
minor = new backwards-compatible/non-default features added
micro = pure bugfixes

i.e. 10.X.Y.Z

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE