-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
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
Conversation
src/Composer/Command/ShowCommand.php
Outdated
return floor($diff->days / 7) . ' weeks ago'; | ||
} | ||
|
||
return $releaseDate->format('Y-m-d'); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
src/Composer/Command/ShowCommand.php
Outdated
return floor($diff->days / 7) . ' weeks ago'; | ||
} | ||
|
||
return $releaseDate->format('Y-m-d'); |
There was a problem hiding this comment.
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".
…ckage in --latest/outdated mode, fixes composer#11737
…r latest package in --latest mode (composer#11762)
Fixes #11737