Suggestion -- new field: "Release Date" [added!]

[webfork]

... and also the Flag of the author's country

The flag idea has been covered before: http://www.portablefreeware.com/forums/ ... 18&t=21232

[webfork]

You mean, as in the actual release date of the app vs the date at which it was added/updated?

Exactly.

As an experiment, I put the release date in the version box for the Bitvise SSH update today:

• BitviseSSHClientPortable v6.03 (July 5, 2014)

Does that work?

[Midas]

As an experiment, I put the release date in the version box for the Bitvise SSH update today:

• BitviseSSHClientPortable v6.03 (July 5, 2014)

• To lessen ambiguity, why not use the ISO standard for date representation (cf. http://en.wikipedia.org/wiki/ISO_8601)?
  
  • Thus: 2014-06-05 (separators are entirely optional)...

[SYSTEM]

As an experiment, I put the release date in the version box for the Bitvise SSH update today:

• BitviseSSHClientPortable v6.03 (July 5, 2014)

• To lessen ambiguity, why not use the ISO standard for date representation (cf. http://en.wikipedia.org/wiki/ISO_8601)?
  
  • Thus: 2014-06-05 (separators are entirely optional)...

Sigh. Date formats are a mess. See http://en.wikipedia.org/wiki/Date_format_by_country.

The most important property of a date format is the order of date components: big-endian, little-endian or middle-endian. All three orders are used, and even the most weird one, middle-endian, is used in an important area: United States.

I'd really like ISO 8601 to take off, but it doesn't seem realistic. For any normal person, all date formats except the local ones will feel weird. That applies to me as well: I know the big-endian format, used in ISO 8601, is the most reasonable format (in particular, it matches the time format), but yet it feels weird for me because everyone uses little-endian in Finland.

For the issue at hand, any format is fine as long as the month is spelled out with letters instead of numbers. Such a format is unambiguous. The order of date components will feel weird for some visitors, but that's unavoidable.

[Midas]

A little weirdness in exchange for a wider understanding seems like a good trade for me.

One viable alternative, per your rationale and perhaps still standard conformant, would be 2014-JUN-05 -- supposedly, the 3 letter month indicator can easily be converted to the corresponding digits...

My local "natural" format would also be the one you refer to as little endian, but ISO 8601 made it to an EU directive and, little by little, it is catching on, since it works without conversion in lists and tables.

[webfork]

why not use the ISO standard for date representation

Ugh. Without getting into a lot of backstory, this has been a big thing for me for years. Almost everything on my machine is in that format. When I saw this from XKCD I just sighed.

The reason I went with that format is the only reason Americans haven't switched over to metric yet: people are used to a particular format; if someone told me they were 1.24 meters tall, I still don't know offhand what that means. (Is that short?) As such, I went with what I think is the most friendly and familiar. I think everyone that's not an engineer looks at a collection of numbers and just filters it out.

Anyway. Should I put the release date in more version fields or is that a dumb idea?

[Midas]

Almost everything on my machine is in that format. When I saw this from XKCD I just sighed.

• Makes sense. XKCD is only pointing the way to those who think otherwise...

if someone told me they were 1.24 meters tall, I still don't know offhand what that means. (Is that short?)

• As short as an infant... or a midget.
  
  As a rule of thumb, if you discard the integer from the metric height, you get a rough estimate of the ideal weight for a given individual...

I think everyone that's not an engineer looks at a collection of numbers and just filters it out.

Anyway. Should I put the release date in more version fields or is that a dumb idea?

• Not me -- and I'm a humanities major. As for filling the dates in, I think that right now you should decide case by case. It's yet another humongous updating chore and it won't add much to most entries. As I see it, only the really old or entries with high frequency updates will benefit...

[SYSTEM]

why not use the ISO standard for date representation

Ugh. Without getting into a lot of backstory, this has been a big thing for me for years. Almost everything on my machine is in that format. When I saw this from XKCD I just sighed.

The reason I went with that format is the only reason Americans haven't switched over to metric yet: people are used to a particular format; if someone told me they were 1.24 meters tall, I still don't know offhand what that means. (Is that short?) As such, I went with what I think is the most friendly and familiar. I think everyone that's not an engineer looks at a collection of numbers and just filters it out.

I found an appropriate picture:

[webfork]

I found an appropriate picture

Here's another: countries not using the Metric system (in red):

http://www.zmescience.com/other/map-of- ... ic-system/

[bzl333]

what about adding release date again? i vote YES.

[webfork]

what about adding release date again? i vote YES.

Point taken. Still, it's really up to Andrew. I don't know what to do as far as adding the date to the version number ... I'm just not sure that makes sense.

[Andrew Lee]

Maybe we can add the field (for display) but not use it in sorting.

There are two problems involved in sorting on this field:

1) Since it is an optional field, and assuming a sizable number of entries don't have this info (and use the default update date instead), then the sorting is meaningless because we are not comparing apples with apples.

2) If we introduce a third sorting method and hide those entries without release dates, then it introduces extra complexity for the user. If we don't hide those entries, then the sorting becomes meaningless again.

I would argue that just having the field displayed where available will allow interested users to quickly gauge whether it is worth their while to investigate the app further.

This update activity level is only applicable in a narrow range of use cases. Most of the time, we are just looking for an app that fulfill our requirements and run on our systems, even if it has been released years ago and haven't been updated since, as long as it does the job.

What do you think?

[carbonize]

People seem to forget that America is not the only one still using Imperial system. Here in the UK we are only partially metric. We still drive in MPH, drink pints, give our height in feet and inches and weight in stones.

As to the date issue can't we just store a timestamp and then registered users can specify their chosen format and everyone else gets whatever you decide to give them?

[SYSTEM]

Maybe we can add the field (for display) but not use it in sorting.

There are two problems involved in sorting on this field:

1) Since it is an optional field, and assuming a sizable number of entries don't have this info (and use the default update date instead), then the sorting is meaningless because we are not comparing apples with apples.

2) If we introduce a third sorting method and hide those entries without release dates, then it introduces extra complexity for the user. If we don't hide those entries, then the sorting becomes meaningless again.

I would argue that just having the field displayed where available will allow interested users to quickly gauge whether it is worth their while to investigate the app further.

I think it would best to simply show the entries without release date information last.

This update activity level is only applicable in a narrow range of use cases. Most of the time, we are just looking for an app that fulfill our requirements and run on our systems, even if it has been released years ago and haven't been updated since, as long as it does the job.

What do you think?

It depends on the use case. Especially if I'm looking for a program that has security impact (e.g. any Internet related program), I certainly don't want to pick one that is no longer being developed.

[bzl333]

I would argue that just having the field displayed where available will allow interested users to quickly gauge whether it is worth their while to investigate the app further.


What do you think?

^^ i agree with that. it also helps if you're checking to see if you have the latest version and you see the release date is say a year ago or more, then you have a pretty good idea.