Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add release date to show command, and also release date for latest package in --latest/outdated mode #11762

Merged
merged 3 commits into from Dec 20, 2023

Conversation

Seldaek
Copy link
Member

@Seldaek Seldaek commented Dec 19, 2023

Fixes #11737

@Seldaek Seldaek changed the title Add release date to show command, and also release date for latest pa… Add release date to show command, and also release date for latest package in --latest/outdated mode Dec 19, 2023
@Seldaek Seldaek added this to the 2.7 milestone Dec 19, 2023
return floor($diff->days / 7) . ' weeks ago';
}

return $releaseDate->format('Y-m-d');
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After a month I revert to just a date here. I don't know if X months ago would bring much more value or not? Any opinions?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The key difference here is whether it's when a package was released or how old is a package. I think most of the time a developer wants to know the latter and displaying the date will force the developer to calculate the age in head. I would leave the relative time on the list and use a date or date + relative time when single package is provided as an argument (here we don't have to think about terminal witdh as we do on the list output).

Secondly, these are old packages that we are interested in most of the time - installed packages with versions released this week, last week or 3 weeks ago will not probably be candidates for an upgrade (I bet most of teams upgrade dependencies once a year or twice a year at maximum)

IMO we could add also "x months ago" and for packages older than 1 year use "over a year ago".

Copy link
Member Author

@Seldaek Seldaek Dec 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also note that I am showing the time since the release of the new package, not the old one. Were you expecting to see the old one? I am not sure what value either of these infos gives you in the outdated list view tbh.

Edit: I see in your other comment you indeed expected the old/current version's release date. I'm not sure how relevant it is though, whether something was released six months ago or yesterday, if there is a new release fixing things why not update?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The whole point of this feature I have proposed is to have a big picture of how old my dependencies are and based on that decide whether the team should put an upgrade on the roadmap. Many teams don't upgrade when there is a new release but do it once or twice a year. For now I have my own script that parses composer.lock and composer.json and outputs the packages from oldest to latest but I thought it would be nice to have it out of the box.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I added a --sort-by-age / -A flag now, so it shows the installed package's age only when the flag is used, and it also sorts then. That removes the confusion about what date is even shown as it is documented and opt-in.

return floor($diff->days / 7) . ' weeks ago';
}

return $releaseDate->format('Y-m-d');
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The key difference here is whether it's when a package was released or how old is a package. I think most of the time a developer wants to know the latter and displaying the date will force the developer to calculate the age in head. I would leave the relative time on the list and use a date or date + relative time when single package is provided as an argument (here we don't have to think about terminal witdh as we do on the list output).

Secondly, these are old packages that we are interested in most of the time - installed packages with versions released this week, last week or 3 weeks ago will not probably be candidates for an upgrade (I bet most of teams upgrade dependencies once a year or twice a year at maximum)

IMO we could add also "x months ago" and for packages older than 1 year use "over a year ago".

src/Composer/Command/ShowCommand.php Outdated Show resolved Hide resolved
doc/03-cli.md Outdated Show resolved Hide resolved
doc/03-cli.md Outdated Show resolved Hide resolved
src/Composer/Command/OutdatedCommand.php Outdated Show resolved Hide resolved
src/Composer/Command/ShowCommand.php Outdated Show resolved Hide resolved
src/Composer/Command/ShowCommand.php Show resolved Hide resolved
src/Composer/Command/ShowCommand.php Show resolved Hide resolved
@Seldaek Seldaek merged commit 53a1f32 into composer:main Dec 20, 2023
20 checks passed
@Seldaek Seldaek deleted the latest_date branch December 20, 2023 14:42
theoboldalex pushed a commit to theoboldalex/composer that referenced this pull request Jan 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add the time a package was released in composer show command
3 participants