-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
Release names are hard to read. #641
Comments
I think it not hard. |
Why not 2016-04-25_12:05:00? |
Easy read but not good for computer 😄 |
Yeah why not? In my example I just tried to kill two birds in one stone by adding microsecs so that all releases have the same format, even if you launch two of them in the same second. To me the MySQL datetime format would be even better.
Eh? wut about |
You can make a Datetime object from string |
If you want easy for create a date time object, why you make a custom task |
@oanhnn Thanks for responding, but your points are moot...
Same with // If you're into parsing dates with regexps
preg_match('/^(?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2})_(?<hour>\d{2}):(?<min>\d{2}):(?<sec>\d{2})\.(?<usec>\d{6})$/', $releaseName, $matches);
// But way better...
DateTime::createFromFormat('Y-m-d_H:i:s.u', '2016-05-01_20:00:00.123456');
// BTW, a REAL regexp for parsing a datetime would be IMPOSSIBLE
Well,
2016-05-01_20:00:00 is exactly as easy to compare for a machine, and easier to compare for a human eye...
Thanks for the suggestion, that's what I did, see my first comment. 😉 |
@oanhnn i think it's good for DX by more friendly. What are you think? Whats cons? |
|
One
TwoUrl ThreeCompare
|
@oanhnn So many bikes were shed. 🚴 |
Really, guys. Release number needed only for developers who watching releases lists. |
Guys, vote for Y-m-d_H:i:s with 👍🏻 , and for YmdHis with 👎 |
👍 |
Please do not insert colons in auto-generated filenames. These characters will produce several problems on different systems! Especially Windows struggle with some filenames but these characters run into several problems on Unix-Systems also.
Anyway the readability of the filename is learning thing at first. And I struggle more with a too human readability format in some programmatic cases. So my vote is definitely against the new format because it will cause several problems which we can't see in a first glance, although I like readable formats. But not in cases which usually are not reviewed by humans all the time. And to bring a knockout argument, other solutions like capistrano use the current format as well. 👎 |
Agree, i think we can leave current YmdHis format, and implement something like a new command for $ dep releases
| Path | Date | Author | Broken | ...
| .... | |
@Elfet That's a really good proposal, I like it and it fixes the problem in a much cleaner way. Furthermore it can carry some more information as you already mentioned. |
New format in v4. |
Description
Hi,
I find the current way of naming release hard to read, especially if you have several of them during the same day/hour.
Couldn't it be a bit more human friendly in future versions ?
For example:
This way you have releases that look like:
Which is quite more readable than
Don't you think ? 😉
The text was updated successfully, but these errors were encountered: