starred/youtube-dl

Fork 0

mirror of https://github.com/ytdl-org/youtube-dl.git synced 2026-03-02 23:07:04 -05:00

version update #26203

New issue

Open

opened 2026-02-21 13:01:24 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-21 13:01:24 -05:00

Owner

Originally created by @vstavrinov on GitHub (Apr 14, 2023).

Checklist

I'm reporting a feature request
I've verified that I'm running youtube-dl version 2021.12.17
I've searched the bugtracker for similar feature requests including closed ones

Description

version 2021.12.17 looks too old. Please use versioningit to make it more relevant reflecting resent updates

Originally created by @vstavrinov on GitHub (Apr 14, 2023).  ## Checklist  - [x] I'm reporting a feature request - [x] I've verified that I'm running youtube-dl version **2021.12.17** - [x] I've searched the bugtracker for similar feature requests including closed ones ## Description  version 2021.12.17 looks too old. Please use versioningit to make it more relevant reflecting resent updates

deekerman added the

request

label

2026-02-21 13:01:24 -05:00

deekerman commented

2026-02-21 13:01:26 -05:00

Author

Owner

@dirkf commented on GitHub (Apr 14, 2023):

Duplicate of #31585

@dirkf commented on GitHub (Apr 14, 2023): Duplicate of #31585

deekerman commented

2026-02-21 13:01:29 -05:00

Author

Owner

@vstavrinov commented on GitHub (Apr 15, 2023):

@dirkf :

Duplicate of #31585

This is not duplicate. This issue is not about an update problem and not about new release that is overdue as You say. I don't care about overdue release and I have no problem with update as I am using git.

This issue is about version itself as such. The problem is that while I am updating the code in regular basis the --version option always report the same version. So if You deal with few instances You don't know what code You are using excatly.

With versioningit You could solve this problem easily. It generate unique version for last commit. You can define format of that version. You can for example define that tag will be the main part (2021.12.17 for now) and remaining suffix will depend from the commit. This is quick and convenient solution. And this solution doesn't break Your current paradigm and for the release it will report version as tag exactly as it do for now.

@vstavrinov commented on GitHub (Apr 15, 2023): @dirkf : > Duplicate of #31585 This is not duplicate. This issue is not about an update problem and not about new release that is overdue as You say. I don't care about overdue release and I have no problem with update as I am using git. This issue is about version itself as such. The problem is that while I am updating the code in regular basis the --version option always report the same version. So if You deal with few instances You don't know what code You are using excatly. With versioningit You could solve this problem easily. It generate unique version for last commit. You can define format of that version. You can for example define that tag will be the main part (2021.12.17 for now) and remaining suffix will depend from the commit. This is quick and convenient solution. And this solution doesn't break Your current paradigm and for the release it will report version as tag exactly as it do for now.

deekerman commented

2026-02-21 13:01:29 -05:00

Author

Owner

@dirkf commented on GitHub (Apr 16, 2023):

Fair point, which I did actually realise after closing this.

In my own project I'd probably increment the version immediately after a release with some sort of "work-in-progress" indicator and then make the actual version at the point of release. Some other projects have an odd version for WIP/unstable and an even for stable. However yt-dl hasn't done so and some new approach probably ought to be considered.

If you're running the youtube-dl command with updated module code, it doesn't reveal that. If you run it in the git tree with python -m youtube_dl -v ... it lists the git HEAD.

@dirkf commented on GitHub (Apr 16, 2023): Fair point, which I did actually realise after closing this. In my own project I'd probably increment the version immediately after a release with some sort of "work-in-progress" indicator and then make the actual version at the point of release. Some other projects have an odd version for WIP/unstable and an even for stable. However yt-dl hasn't done so and some new approach probably ought to be considered. If you're running the `youtube-dl` command with updated module code, it doesn't reveal that. If you run it in the git tree with `python -m youtube_dl -v ...` it lists the git HEAD.

deekerman commented

2026-02-21 13:01:29 -05:00

Author

Owner

@vstavrinov commented on GitHub (Apr 17, 2023):

@dirkf:

Fair point, which I did actually realise after closing this.

This my fault. I should've explain the problem more detailed first.

In my own project I'd probably increment the version immediately after a release with some sort of "work-in-progress" indicator and then make the actual version at the point of release. Some other projects have an odd version for WIP/unstable and an even for stable. However yt-dl hasn't done so and some new approach probably ought to be considered.

Again the issue is not about stable, unstable or 'work-in-progress' indicator. This issue is about generating unique version to identify exactly the commit it correspond. You don't need to invent bicycle. There is best practice already exists. Here is example.

5.4.0+6.gcb7edb6e

This is version reported by code itself outside of the git tree. It consists of 3 parts:

5.4.0

This first part is the last tag that is the same as last release. You could consider it as main version or release

6

This second part is number of commits elapsed since last tag (release)

cb7edb6e

And finally this third part is short unique representation of commit hash that is it's beginning. Two others symbols i.e. + and .g are delimiters. All parts and delimiters are configurable. For example you can omit second or third part. This example of configuration is very convenient as using third part as pattern You could easily find the commit in git log, while the second part show how far You are ahead of the last release. At the same time with this configuration only first part will be reported for any release. And You don't need to do some special configuration for release, it happens automatically as for release two last parts just doesn't exists (as before, we assume the release is the same as tag).

If you're running the youtube-dl command with updated module code, it doesn't reveal that. If you run it in the git tree with python -m youtube_dl -v ... it lists the git HEAD.

As mentioned above the version reporting should not be tied to git tree. The example above is working for a code installed for example with pip. Other installation tools give the same result as version generation is part of the installation process.

To be closer for Your code here is real example. At this moment versioningit generate this version for my fork of your repository:

2021.12.17.290

As You could see there are no third part and second part is 290 number of commits elapsed since last release of 2021.12.17 . See the exact configuration for this pattern:

https://github.com/vstavrinov/youtube-dl/blob/master/pyproject.toml

And the first example is taken from other project:

https://github.com/streamlink/streamlink/blob/master/pyproject.toml

I hope all these examples help you to design your own solution.

@vstavrinov commented on GitHub (Apr 17, 2023): @dirkf: > Fair point, which I did actually realise after closing this. This my fault. I should've explain the problem more detailed first. > In my own project I'd probably increment the version immediately after a release with some sort of "work-in-progress" indicator and then make the actual version at the point of release. Some other projects have an odd version for WIP/unstable and an even for stable. However yt-dl hasn't done so and some new approach probably ought to be considered. Again the issue is not about stable, unstable or 'work-in-progress' indicator. This issue is about generating unique version to identify exactly the commit it correspond. You don't need to invent bicycle. There is best practice already exists. Here is example. `5.4.0+6.gcb7edb6e` This is version reported by code itself outside of the git tree. It consists of 3 parts: `5.4.0` This first part is the last tag that is the same as last release. You could consider it as main version or release `6` This second part is number of commits elapsed since last tag (release) `cb7edb6e` And finally this third part is short unique representation of commit hash that is it's beginning. Two others symbols i.e. `+` and `.g` are delimiters. All parts and delimiters are configurable. For example you can omit second or third part. This example of configuration is very convenient as using third part as pattern You could easily find the commit in git log, while the second part show how far You are ahead of the last release. At the same time with this configuration only first part will be reported for any release. And You don't need to do some special configuration for release, it happens automatically as for release two last parts just doesn't exists (as before, we assume the release is the same as tag). > If you're running the `youtube-dl` command with updated module code, it doesn't reveal that. If you run it in the git tree with `python -m youtube_dl -v ...` it lists the git HEAD. As mentioned above the version reporting should not be tied to git tree. The example above is working for a code installed for example with pip. Other installation tools give the same result as version generation is part of the installation process. To be closer for Your code here is real example. At this moment versioningit generate this version for my fork of your repository: `2021.12.17.290` As You could see there are no third part and second part is `290` number of commits elapsed since last release of `2021.12.17` . See the exact configuration for this pattern: https://github.com/vstavrinov/youtube-dl/blob/master/pyproject.toml And the first example is taken from other project: https://github.com/streamlink/streamlink/blob/master/pyproject.toml I hope all these examples help you to design your own solution.

deekerman commented

2026-02-21 13:01:29 -05:00

Author

Owner

@dirkf commented on GitHub (Apr 26, 2024):

Nowadays, from https://github.com/ytdl-org/youtube-dl/issues/32772#issuecomment-2080266676:

If you are using the nightly release, as recommended, you get a sensible version number.

@dirkf commented on GitHub (Apr 26, 2024): Nowadays, from https://github.com/ytdl-org/youtube-dl/issues/32772#issuecomment-2080266676: >If you are using the nightly release, as recommended, you get a sensible version number.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/youtube-dl#26203

No description provided.

Rows
Columns