Package: devscripts
Severity: wishlist

Currently pretty=describe takes latest tag and the commit hash, but sometimes the tags are not updated but version is updated in package.json.

Example lodash-cli

https://github.com/bnjmnt4n/lodash-cli

Current version in archive is 4.17.5 but git mode pretty=describe shows 4.17.4.20.hash which is lower than latest tag. But actual version we want is 4.17.21 present in package.json.

It could be another option like pretty=package.json

Hi,

`pretty=describe` uses the result of `git describe`. You got a
"4.17.4.20" because this is the last tag on the branch you tried to
clone. The "4.17.5" tag is attached to a different branch (unnamed).

So uscan is right here ;-)

Cheers,
Yadd

I don't think uscan is right here. The correct version is available in the package.json. I think it'd be a nice option if uscan can pick the version available in package.json instead of us adding it manually for every update. I currently have to hard code the version in watch file which I don't think is a right solution.

Tag is only one way of finding the version and often not used by node projects. package.json is also a way to find the version of the node module and consistently used by all node modules. Since we already have a type=nodejs we know it has a package.json.

Le 21/04/2021 à 17:23, Pirate Praveen a écrit :
after last tag. Upstream did a strange thing in this repo: set a tag
outside any named branch. I'm not sure we should modify uscan because of
an unlikely upstream behavior.
But if Devscript Team agree with you, I can modify "ctype" feature to
fix tag when last tag is lower than package.json#version, then version
will be 4.17.5+timestamp instead of 4.17.4.20+timestamp

Cheers,
Yadd

Control: reopen -1

I have reopened for comments from devscripts team.

It does not have to be the default, but as an optional setting in the watch file. May be ctype=nodejs,version=package.json

Or ctype=nodejs,pretty=package.json

In this case it should be 4.17.21+git.timestamp.hash as version in package.json is 4.17.21.

uscan supports a lot of weird upstream conventions anyway. Many upstream don't use tags consistently so we need ways to handle those cases.

Also checksum option does not support mode=git scheme default values. So I used pretty=4.17.21.%cd to force using digits only.

Should I open another bug for using checksum with git ? Current it supports only digits in version so ~git or +git or the hash in version does not work.

I do agree this is a very odd behaviour, and likely a unique one.  In
this case it's not a forgotten tag, is a tag that is not an ancestor of
what you downloaded.   (that said, I can't see such tag in my clone of
bnjmnt4n/lodash-cli ?  So, what are you talking about?)
this, I'd like at least another package where this actually proves
useful and preferably more than one more.

Besides, in this case it's not even that useful, IMHO.
Since you are using the group+checksum feature, the actual version that
uscan gets from the lodash-cli component is very hidden and doesn't
really matter in the end, as long it monotonically increases whenever
there is an updated upstream, which I believe it does in your watchfile.

Well, I would rather we do not add more support for more weird
upstreams.  There used to be a time when we tried to collaborate with
upstreams to get something that works for both, and I honestly believe
that asking them to create tags whenever they release something is
totally acceptable and you should do that.  Did you try here?  What
answer did you get?

Well, for this, whatever Yadd prefers.  I guess forcing a different
pretty= format with version `checksum` is fine to do and probably makes
sense if it fails otherwise.

On Sat, Apr 24, 2021 at 1:53 pm, Mattia Rizzolo <mattia@debian.org> wrote:

This particular combination may be unique, but not having a recent tag
is not unique at all. In many repos, the tags stops after some releases
for many releases. They stop tagging.

This list is just from 2 pages of 7 pages of open issues I have in
github (some pages even have 8 requests patching tag - see the
screenshot).

https://github.com/arcanis/clipanion/issues/72
https://github.com/differui/rollup-plugin-sass/issues/73
https://github.com/tylingsoft/dagre-d3-renderer/issues/6
https://github.com/tylingsoft/dagre-layout/issues/4
https://github.com/tylingsoft/graphlibrary/issues/3

Any project that does not use tags or don't update tags benefit from
this scheme. Many times I have to look in commit logs to find the
version bumps and use that commit. But package.json version is
consistently updated in every node module.

I have to manually bump this version everytime. May be not an issue in
this particular case. But from a node modules point of view, the
canonical source of truth regarding version is package.json, not tags.

Yes, I do ask them. But sometimes they don't respond at all. For
example https://github.com/arcanis/clipanion/issues/72 and more linked
above.

https://github.com/bebanjo/delorean/issues/22 this request is pending
from 2013 (a ruby project though, just giving an example).

ok. I'll open another bug.