Deployer: Release names are hard to read.

[ju1ius]

| Q | A |
| --- | --- |
| Issue Type | Feature Request |
| Deployer Version | 3.2 |
| Local Machine OS | N/A |
| Remote Machine OS | N/A |

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:

// recipe/common.php
/**
 * Release
 */
task('deploy:release', function () {
    $releaseDir = env()->parse("{{deploy_path}}/releases");

    $guard = 42;
    do {
        $time = microtime();
        list($usec, $sec) = explode(' ', $time);
        $date = \DateTime::createFromFormat('U.u', $sec . '.' . ($usec * 1e6));
        $releaseName = $date->format('Y-m-d_H:i:s.u');
        $releasePath = $releaseDir . '/' . $releaseName;
    } while (is_dir($releasePath) && --$guard);

    env('release_name', $releaseName);

    run("mkdir $releasePath");

    run("cd {{deploy_path}} && if [ -h release ]; then rm release; fi");

    run("ln -s $releasePath {{deploy_path}}/release");
})->desc('Prepare release');

This way you have releases that look like:

+ releases
|-- 2016-04-25_12:05:00.011813
|-- 2016-04-25_18:01:02.614783
|-- 2016-04-26_12:00:03.314854
|-- 2016-04-26_18:03:00.214896
|-- 2016-04-27_12:00:12.114936
|-- 2016-04-27_18:02:33.014975
|-- 2016-04-28_12:04:45.015015
|-- 2016-04-28_18:00:07.215054
|-- 2016-04-29_12:01:18.115094
\-- 2016-04-29_18:00:00.415149

Which is quite more readable than

+ releases
|-- 20160425120500
|-- 20160425180102
|-- 20160426120003
|-- 20160426180300
|-- 20160427120012
|-- 20160427180233
|-- 20160428120445
|-- 20160428180007
|-- 20160429120118
\-- 20160429180000

Don't you think ? :wink:

[oanhnn]

I think it not hard.
I vote using 20160427180233

[antonmedv]

Why not 2016-04-25_12:05:00?

[oanhnn]

Easy read but not good for computer :smile:

[ju1ius]

Why not 2016-04-25_12:05:00?

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.
In the end the exact format should be a good balance between human & machine readability (which is why there are date format RFCs btw).

To me the MySQL datetime format would be even better.

Easy read but not good for computer

Eh? wut about DateTime::createFromFormat('whatever') ???
And if you're really lazy, then just replace "_" by either "" or "T"...

[oanhnn]

You can make a Datetime object from string 20160501200000 by preg_match .
But when you access folder 2016-05-01_20:00:00 via ftp or http, what is url you type? It not friendly.
String 20160501200000 is easy for compare, it very important wit a version label.

[oanhnn]

If you want easy for create a date time object, why you make a custom task deploy:release to make timestamp as version label :smile:

[ju1ius]

@oanhnn Thanks for responding, but your points are moot...

You can make a date time object from string 20160501200000 by preg_match .

Same with 2016-05-01_20:00:00... :confused:

// 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

But when you access folder 2016-05-01_20:00:00 via ftp or http, what is url you type? It not friendly.

Well, http://example.com/2016-05-01_20:00:00/ :laughing:

String 20160501200000 is easy for compare, it very important wit a version label.

2016-05-01_20:00:00 is exactly as easy to compare for a machine, and easier to compare for a human eye...

If you want easy for create a date time object, why you make a custom task deploy:release to make timestamp as version label

Thanks for the suggestion, that's what I did, see my first comment. :wink:
My proposal was making the default format more human friendly, for accessibility reasons (while at the same time narrowing potential race conditions, but that's another story).

[antonmedv]

@oanhnn i think it's good for DX by more friendly. What are you think? Whats cons?

[antonmedv]

| Y-m-d_H:i:s | YmdHis |
| --- | --- |
| + human friendly | - hard to read |
| - break bc | + no break bc |

[oanhnn]

@ju1ius

One

// If you're using
DateTime::createFromFormat('Y-m-d_H:i:s.u', '2016-05-01_20:00:00.123456');

// Why not?
DateTime::createFromFormat('YmdHis', '20160501200000');

Two

Url http://example.com/2016-05-01_20:00:00/ is not friendly.
Therefore, we often created slug by replacing : by -

Three

Compare 20160501200000 as string faster 2016-05-01_20:00:00
Compare 20160501200000 as number (big integer) is good, but 2016-05-01_20:00:00 is not

| Feature | Y-m-d_H:i:s | YmdHis |
| --- | --- | --- |
| Datetime::createFromFormat | true | true |
| URL Slugged | false | true |
| Compare as string | true | true, faster |
| Compare as number | false | true |

[ju1ius]

@oanhnn
One: For accessibility.
Two: we create slugs for SEO. : is a perfectly valid URL character. Please re-read rfc3986. (Btw I seriously hope you do not publicly expose your release paths on the web.)
Three: great! seriously, you'll win a few millisecs when comparing tens of thousands of strings. When you get to that point, your IO operations will take several orders of magnitude longer than the string comparison. We're talking about a web application deployment tool here, not a game engine...

So many bikes were shed. :bicyclist:

[antonmedv]

Really, guys. Release number needed only for developers who watching releases lists.
I that case Y-m-d_H:i:s is better.
Release path should not be a part of URL. And how often you compare releases dates?

[antonmedv]

Guys, vote for Y-m-d_H:i:s with 👍🏻 , and for YmdHis with 👎

[mbardelmeijer]

:+1:

[nemoinho]

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.
The following characters are reserved on Win:

• < (less than)
• > (greater than)
• : (colon)
• " (double quote)
• / (forward slash)
• (backslash)
• | (vertical bar or pipe)
• ? (question mark)
• * (asterisk)

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.

👎

[oanhnn]

| Feature | Y-m-d_H:i:s | YmdHis | Ref |
| --- | --- | --- | --- |
| Human friendly | true | false | |
| Break BC | true | false | |
| Safe for other OS | false | true | ref1 ref2 ref3 |
| Safe for ZIP | false | true | ref4 |
| Datetime::createFromFormat | true | true | |
| URL Slugged | false | true | |
| Compare as string | true | true, faster | |
| Compare as number | false | true | |
| Vote | :+1: | :-1: | |

:-1:

[antonmedv]

Agree, i think we can leave current YmdHis format, and implement something like a new command for deb, which will be showing releases lists in human friendly format:

$ dep releases
|   Path   |    Date    |    Author    |    Broken   | ... 
|   ....   |

[nemoinho]

@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.

[antonmedv]

New format in v4.