Re: Feature idea: show upstream release dates on packages
On Thu, Jul 03, 2025 at 08:42:52AM -0400, Dan Ritter wrote:
> Borden wrote:
> > On a few projects, I've discovered how ancient some software is (like, last commit more than 15 years ago ancient). Unless I missed something, `apt-cache show` doesn't show the upstream release date.
Ignoring the usual gripes about outdated software versions in stable, this
seems like a pretty great idea. I am not sufficiently familiar with the
.deb metadata format, but I suspect including an Upstream-Version field
to any given package would be trivial. Displaying that field in apt-cache
show may or may not require a minor code change.
> This runs into problems quickly. Relevant issues include:
s/problems/exceptions/
> - no upstream ever existed
> - the upstream no longer exists
Okay, sure, and it's entirely reasonable to note that in the Upstream-Version
field.
> - the upstream doesn't release; the DD had to pick a particular
> git/svn/hg... version and use that
That can also be noted with an identifier for the commit, which certainly
has a date attached.
> - the official release date for the version was X, but this is
> the eleventh time a DD has patched in fixes from later
> versions
That doesn't change the upstream version the package is based on.
> - the package is synthetic and has multiple release dates,
> possibly including other problems from above
That can be noted in the Upstream-Version field and more details can be
included in the description. Or not.
> - there are roughly 60,000 packages in Trixie. At five minutes
> per package to research the date, make a decision, add the
> header and re-upload, that's 5000 hours of new work you are asking
> volunteers to do. Two and a half years of full-time employment.
I don't think the suggestion was that DDs would have to go through all
previous packages and update them. It makes sense to do this going forward
whenever a new package version is uploaded. Or possibly only when a package
based on a new upstream version is uploaded.
> Is it a plausible idea to suggest? Yes. Is making it mandatory
> for Trixie reasonable? No.
There was absolutely no suggestion that it should be mandatory. It's useful
information that package maintainers can be encouraged to include in a
standardized way. That's it. There is no need to invent burdens.
> -dsr-
--Gregory
Reply to: