Show release date with bundle outdated

[hsbt]

What was the end-user or developer problem that led to this PR?

Fixed #9329

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[Copilot]

Pull request overview

Updates Bundler’s bundle outdated output to include a “Release Date” column (and corresponding --verbose/manpage examples), plus a small test robustness tweak for Rust newgem generation.

Changes:

• Add “Release Date” to bundle outdated table output and (potentially) to parseable output.
• Update bundle outdated specs and manpages to reflect the new column.
• Increase cargo test timeout in newgem specs to reduce flakes.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
bundler/lib/bundler/cli/outdated.rb	Adds release date extraction and prints it in outdated output/table.
bundler/spec/commands/outdated_spec.rb	Updates expected headers for the new “Release Date” column.
bundler/spec/commands/platform_spec.rb	Updates outdated-related expectations to include the new header column.
bundler/lib/bundler/man/bundle-outdated.1.ronn	Updates documentation examples to include “Release Date” and sample dates.
bundler/lib/bundler/man/bundle-outdated.1	Updates generated manpage to match the .ronn changes.
bundler/spec/commands/newgem_spec.rb	Adds a longer timeout for cargo test in the Rust extension skeleton spec.

Comments suppressed due to low confidence (2)

bundler/lib/bundler/cli/outdated.rb:216

• This change alters the --parseable/--porcelain output format by potentially appending a “released …” segment. That output is explicitly intended for machine parsing, so any additional fields should be gated behind an explicit option (or a new dedicated format version) to avoid breaking existing tooling.

      spec_outdated_info = "#{active_spec.name} (newest #{spec_version}, " \
        "installed #{current_version}#{dependency_version}"

      release_date = release_date_for(active_spec)
      spec_outdated_info += ", released #{release_date}" unless release_date.empty?
      spec_outdated_info += ")"

      output_message = if options[:parseable]
        spec_outdated_info.to_s
      elsif options_include_groups || groups.empty?
        "  * #{spec_outdated_info}"
      else
        "  * #{spec_outdated_info} in #{groups_text("group", groups)}"
      end

      Bundler.ui.info output_message.rstrip

bundler/spec/commands/outdated_spec.rb:37

• Specs were updated to expect a new “Release Date” column, but there’s no spec asserting that any actual release date value is printed (all rows remain blank). Add at least one example where a gem has a known packaged date and assert it appears in the new column (and, if supported, in --parseable output).

      expected_output = <<~TABLE.gsub("x", "\\\h").tr(".", "\.").strip
        Gem            Current      Latest       Requested  Groups   Release Date
        activesupport  2.3.5        3.0          = 2.3.5    default
        foo            1.0 xxxxxxx  1.0 xxxxxxx  >= 0       default
        weakling       0.0.3        0.2          ~> 0.0.1   default
        zebra          1.0 xxxxxxx  1.0 xxxxxxx  >= 0       default

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The manpage examples now show concrete release dates in the table output. With the current implementation, release dates are frequently unavailable (and the column will be blank) unless the code explicitly fetches/derives the remote gemspec’s packaged date. Either update the implementation to reliably populate these values or adjust the documentation/examples to reflect when the column can be populated.

[Copilot]

Nit: this adds an extra blank line between example groups, which doesn’t seem intentional and slightly reduces readability in an already-long spec file. Consider removing the redundant empty line.

Suggested change

[Copilot]

release_date_for won't actually surface release dates for the common Rubygems resolution path. When specs come from the dependency API / compact index they are typically Bundler::EndpointSpecification instances; #date on those will be the default SOURCE_DATE_EPOCH-derived value (or nil) and this method returns an empty string, so the new column will usually be blank. To make this feature work, fetch the real remote gemspec date (e.g., via EndpointSpecification's remote spec fetcher) or otherwise obtain the published date from the source, instead of relying on the local #date accessor.

[Copilot]

The default-date suppression compares against Gem::DEFAULT_SOURCE_DATE_EPOCH, but Gem::Specification#date defaults to Gem.source_date_epoch (which may differ when SOURCE_DATE_EPOCH is set). In those environments, gems with no real packaged date can end up showing an arbitrary build-epoch date as the “Release Date”. Consider avoiding calling spec.date when the date wasn’t explicitly set (e.g., check the underlying ivar), or compare against Gem.source_date_epoch using the same normalization RubyGems uses.

Suggested change

	date = spec.date
	return "" unless date
	date = date.utc if date.respond_to?(:utc)
	default_date = Time.at(Gem::DEFAULT_SOURCE_DATE_EPOCH).utc
	# Avoid triggering RubyGems' implicit default date based on SOURCE_DATE_EPOCH.
	unless spec.instance_variable_defined?(:@date)
	return ""
	end
	date = spec.instance_variable_get(:@date)
	return "" unless date
	date = date.utc if date.respond_to?(:utc)
	# Suppress the default build epoch date used by RubyGems when no date is set.
	default_date = Gem.source_date_epoch
	default_date = default_date.utc if default_date.respond_to?(:utc)