tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Versioning unversioned packages



Roland Illig <roland.illig%gmx.de@localhost> writes:

> Am 18.06.2016 um 11:53 schrieb Ryo ONODERA:
>> Hi,
>> 
>> From: Gavan Fantom <gavan%coolfactor.org@localhost>, Date: Fri, 10 Jun 2016 13:13:07 +0100
>> 
>>> Hi folks,
>>>
>>> Occasionally we have packages which are not derived from a specific
>>> release upstream. Sometimes because the last release was a long time
>>> ago and a newer, unreleased, version is needed to do anything useful,
>>> and sometimes because upstream simply hasn't ever made releases and
>>> just expects people to use the latest version from github.
>>>
>>> But in pkgsrc we need a version number for every package. How do we
>>> derive this version number in the case of packages where the author
>>> has not supplied a version number, and we are just stating a revision
>>> in github or similar?
>> 
>> I prefer "pre" or "rc" described in pkgsrc/mk/help/distname.help .
>> For example, 0pre20160618.
>
> Wow, this idea is so simple and effective that I'd like to document it
> as the "official way" in the pkgsrc guide.

I don't like "pre" or "rc", as they are often used by upstream
programs.  Also, pre and rc tend to mean that foo-2.1pre1 is actually
before foo-2.1.   We could end up having "1.2pre3" as the most recent
upstream version, with 1.2 not having appeared.  What do we do then, and
how do we make it sort?

I think we agree that we use an 8-digit ISO8601 date.

What we need here is to agree on two things:

  what version of the upstream package should we use: the most recent
  release, or the release we think will happen next?

  what separator method to use between the upstream version and the date

For version, I think we should use the most recent previous version.  So
if upstream released 1.5, and we think is going to release 1.6 next, we
should have something that is "1.5 <tbd> 20160620".  This makes sorting
right without magic rules about "pre" being before what it is labeling.

We have "nb" as a special separator for PKGREVISION.  Non-releases are
sort of like PKGREVISION in that we apply it to versions, except that
it's an upstream thing, and we need PKGREVISION too, for a different
reason.

So I suggest "ur" to mean "unreleased", and to add it as a separator
token, with the rule that a version is

  version
  [unreleased date]
  [nbrevision]

So that something might look like

  foo-1.5ur20160610nb2
   
we could even have a

  UNRELEASED_VERSION=yyyymmdd

in Makefiles similar to how we have PKGREVISION.

This has slightly (really?) ugly syntax, but is semantically clean.
The way to clean it up is to get upstreams to have releases :-)



A less ugly but slightly unreliable proposal:

I would prefer to just use 1.5.20160610, but we can't be sure that
upstream will release 1.6 and not 1.5.1.  So we'd have to use

  1.5.0.20160610

figuring that the odds that upstream will release 1.5.0.1 next after 1.5
is near zero (for a package where we need to use non-releases).


I'd be fine with either "0.${UNRELEASED_VERSON}" or
"ur${UNRELEASED_VERSION}.

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index