Expose Version#built_at on the versions index page

[nvasilevski]

Hey folks! Me and @Schwad would like to propose a change to the Version index page
We would like to use a bit more accurate date especially for gems that were imported into rubygems on July 25, 2009
Currently all gems use version.created_at (interestingly it was switched from version.built_at) - #1504
but for older versions of gems like nokogiri created_at has not a lot of meaning, for example:
https://rubygems.org/gems/nokogiri/versions

Currently on production for nokogiri

So we went with a little verbose but backwards-compatible approach that falls back to built_at attribute for gems that we consider "imported", or, literally created on July 25th, 2009
Naming was hard so feel free to suggest your options, but we added a new method authored_at that performs this fallback by checking whether the version was seeded? which just compares created_at date to be equal July 25th, 2009 (time part is stripped)

Which results in a nicer and more insightful history of older nokogiri versions:

After using built_at for pre-rubygems gems

Side-to-side comparison

[Schwad]

This is great Nikita, thanks for this! I think it's really clear what we were working on and solving here.

[jenshenny]

+1, this is great work folks 🚀

One thing that I noticed in the PR that was linked about switching from built_at to created_at is that built_at is an author defined field in the gemspec that doesn't abide by any validations. For instance, I found that from gems with a created_at on July 25, 2009, there's a handful of gems with a built_at in the future.

To keep the information as accurate as possible, perhaps for versions before July 25, 2009, we can have the built_at date but have an asterisk beside those dates. We can specify that these versions were the specified built at date but was pushed to rubygems.org on July 25, 2009.

[nvasilevski]

we can have the built_at date but have an asterisk beside those dates. We can specify that these versions were the specified built at date but was pushed to rubygems.org on July 25, 2009.

That makes total sense! I'll make a change
I forgot to mention this, but I definitely admit that using nokogiri as an example is a bit cheaty because I was confident it has proper built_at dates but I definitely was expecting some gems to have inconsistent built_at value 🙃

[nvasilevski]

Update:
Added an asterisk for versions that were imported. Please feel free to suggest the most appropriate wording as I feel like I keep mixing seeded and imported as seeded sounds suitable from an application point of view but from a user point of view imported may have better clarity.

[nvasilevski]

For instance, I found that from gems with a created_at on July 25, 2009, there's a handful of gems with a built_at in the future.

Also added an additional check to fall back to created_at for gems there were imported on July 25th, but authors specified date in the future. This should keep the history consistent.

[Schwad]

This makes sense that we only show it if there are old gem versions

[sonalkr132]

We should update line 7 since: nice_date_for .. created_at to use authored_at.

[nvasilevski]

Good catch, going to update it 👍
Thank you!

[jenshenny]

Thanks @nvasilevski, I just have a couple of questions/suggestions, but otherwise it LGTM!

[qrush]

GitHub ate my email on this, apologies if this goes through twice.

Some background/history on this attribute in case we need is on #1353, also @sonalkr132 did a lot of work in this space too and may want to review this.

I had a 13 year old code flashback as I remember writing the migration to add built_at (and deal with its confusion with created_at) but having trouble recalling the discussion around it. This was before PRs on GitHub and possibly deep in the IRC logs on freenode if those exist somewhere…

[nvasilevski]

Addressed suggestions & rebased on the latest main to remove unrelated translations moves

[Schwad]

I had a 13 year old code flashback as I remember writing the migration to add built_at (and deal with its confusion with created_at) but having trouble recalling the discussion around it. This was before PRs on GitHub and possibly deep in the IRC logs on freenode if those exist somewhere…

My impression is that since created_at was at one point "polluted", or possibly full of data that may have been editable by the author.

So on July 25, 2009 that PR made a copy of that data on built_at and established canonical created_at dates beginning from that date forward.

Although this is quite old, I find this PR incredibly helpful for those of us (like me) who spend a lot of time in "old" ruby and would benefit massively from a possibly more accurate representation of version dates before then.

For example with @flavorjones Bundler::AsOf which lets us bundle a gemfile and resolve dependencies from, say, 2008.

Thanks for the work and feedback everyone

[sonalkr132]

This change seems fine to me. Please make sure that we didn't bulk import versions on any other day as well.
Also, note that this mostly an aesthetic change. No API response or functions which rely on dates will be changed.

[Schwad]

Also, note that this mostly an aesthetic change. No API response or functions which rely on dates will be changed.

I think this makes sense. As the formal api already returns built_at, so for an issue I'm currently working (and others in this position) we can manually revert to built_at for gems imported on the import date.

[nvasilevski]

Update:
We went with a tooltip to make sure the notice is going to be rendered on both Versions#index and RubyGems#show page
Preview:

[sonalkr132]

You should be able to add a modifier class to preserve the version number color. As per your screenshot, ones will tooltip are now red.

[nvasilevski]

Sounds reasonable! I wasn't sure if we want to preserve the color or highlight it to be aligned with other tooltips

I defined .gem__version__date.tooltip__text style explicitly to preserve the color from gem__version__date
Let me know if that is what you meant

[sonalkr132]

This looks much better. Thank you.

[sonalkr132]

This was deployed to prod. One improvement we can make is update the tooltip icon. [?] on some version and not on others, feels wonky. A better icon could be a superscript * next to version number, which would better covey that some version numbers are special/different.