Www.julialang.org: Release dates on download page

[simonbyrne]

It would probably be a good idea to put the release dates on the downloads page, so that people know how old those versions are. This seems pretty standard for most software downloads.

[annainfo]

And have them in ISO 8601 date format YYYY-MM-DD. Time in UTC.

[ararslan]

Having the time seems excessive but formatting the date as YYYY-MM-DD seems appropriate.

[annainfo]

Having the time seems excessive

Without a defined time YYYY-MM-DD is not defined.

[simonbyrne]

Dates are approximate in any case, since builds may take a day or so to complete after release.

[annainfo]

Dates are approximate in any case, since builds
may take a day or so to complete after release.

Why would something that happens "after release" be relevant for the determination of the "release date"? And why would it make the date "approximate"?

[simonbyrne]

Why would something that happens "after release" be relevant for the determination of the "release date"?

Because they're the links for the downloads of the builds.

And why would it make the date "approximate"?

Approximate was a poor choice of word. Basically, my argument is that a 48 hours is sufficient precision for reporting the release date.

As was mentioned on discourse, your overall tone is very combative and not at all conductive to the collaborative nature of this project. Please do consider how your comments might be read by others.

[annainfo]

Because they're the links for the downloads of the builds.

What ("they") are the links? How do links come into the process of determination of the "release date"?

Basically, my argument is that a 48 hours is sufficient
precision for reporting the release date.

Never seen this anywhere else. Might cause confusion if there are two releases within less than 48h, and the later release has lower date.

Github provides minute precision (verify at https://github.com/JuliaLang/julia/tags) and via the API precision to the second ( https://developer.github.com/v3/repos/releases/#list-releases-for-a-repository ) - easy to derive a precise YYYY-MM-DD.

The example shows

• "created_at": "2013-02-27T19:35:32Z"
• "published_at": "2013-02-27T19:35:32Z"

The "Z" indicates that the information is given in UTC, as was proposed by me (https://github.com/JuliaLang/www.julialang.org/issues/150#issuecomment-414412938) . That means one only would need to cut out the first 10 characters of the value of one of these fields.

As was mentioned on discourse, your overall tone
is very combative and not at all conductive to the
collaborative nature of this project.

You might be violating https://julialang.org/community/standards/ .

[ViralBShah]

We are not going to have timestamps along with the dates on downloads. If that is not ISO compliant, that is ok.

[annainfo]

We are not going to have timestamps along with
the dates on downloads. If that is not ISO compliant, that is ok.

Did anyone propose to have "timestamps along with the dates"?

[ViralBShah]

Yes, I thought that is what you were proposing in the second comment above.

[annainfo]

No, I proposed to have YYYY-MM-DD. No time. But since the value depends on the offset from UTC, I proposed to use UTC itself, zero offset.

[ararslan]

Thank you for clarifying your proposal. That indeed makes sense.

[annainfo]

@ViralBShah @ararslan

1) In absence of knowing any other value, I suggest to use one of (taken from the https://developer.github.com/v3/repos/releases/#list-releases-for-a-repository )

• "created_at"
• "published_at"

2) I further suggest to use created_at, since

• publication could take place several times, (per platform, per audience [country - e.g. restrictions on the distribution of software could prohibit publication in a certain country for some time]
• it is the lowest value of these two

[ViralBShah]

@ararslan I think the simplest thing that is useful is to add a download date to the release table or in the release version subtitle.

[ararslan]

That seems reasonable.

[ViralBShah]

@ararslan Bumping to see if you think we can start doing this.