When you have a release for the first time, how do you name your release version based on SemVer? 1.0.0, 0.1.0 or 0.0.1?

I like to start off with 0.1.0. Because version 0.0.0 means there is nothing. Then from nothing to something, that’s breaking change, hence version 0.1.0.

I was planning to build two different Docker images: one for production and one for test. However, the more I had coded, the more frustrated I had become. I want something simple, and more means complexity:

1. Having multiple images means more configuration files to manage and update.
2. More things to do when working with third-party tools, for example, Google App Engine Managed VMs deployment will only recognize the application root level Dockerfile out of the box.
3. Steeper learning curve for new developers.

Keep our application structure simple is important. If you need multiple dockerfiles, then your application is too complex. The difference between npm install --production and npm install isn’t a lot. But it will save you time and effort from managing multiple dockerfiles. There is no reason to have more than one Dockerfile. Just use a different command such as npm test when running tests.

A changelog starter to be consistent with my coding style:

• Two header levels only with setext style.
• Use underlines for first-level headers and dashes for second-level headers.
• Each release is a section, hence use second-level header.
• Each category in a release is not a section, hence use emphasis with double asterisks.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

Changelog
=========
Guideline:
1. Record notable changes.
2. List releases in reversed chronological order, newest on top.
3. Write all dates in `YYYY-MM-DD` format.
4. Follow [SemVer] format for each release.
5. Creating a new release by copying the **Example** section (on the bottom)
   to the top and rename it **Unreleased**.
6. Keep an **Unreleased** section on top for tracking any changes in order to
   minimize required effort.
7. Change _Unreleased_ to a release name with the date when ready.
_The guideline attempts to follow [Keep a CHANGELOG][1]._
[SemVer]: http://semver.org/
[1]: http://keepachangelog.com/
0.1.0 / 2015-01-01
------------------
**Security**
 - Inform users to upgrade for vulnerabilities.
**Removed**
 - Remove a deprecated feature in this release.
**Deprecated**
 - Deprecate a feature in the upcoming release.
**Changed**
 - Change an existing functionality.
**Added**
 - Add a new feature.
**Fixed**
 - Fix a bug.
Example / YYYY-MM-DD
--------------------
**Security**
 - Inform users to upgrade for vulnerabilities.
 - Each sentence must use the present tense and ends with a period.
**Removed**
 - Remove a deprecated feature in this release.
 - Basic Authentication is dropped in favor of Digest Authentication.
**Deprecated**
 - Deprecate a feature in the upcoming release.
 - Basic Authentication will be replaced by Digest Authentication in the next
   release.
**Changed**
 - Change an existing functionality.
 - User session data is added to the user object upon initialization.
**Added**
 - Add a new feature.
 - A new endpoint `/users` is added to handle user CRUD.
**Fixed**
 - Fix a bug.
 - Add the default case to handle unknown cases in user group assigning.

We frequently find ourselves need to define array of objects. In CoffeeScript we can write in the following way:

1
2
3
4
5
6
7
8
9
10

arr = [
  {
    name: 'foo'
    pass: 'oof'
  }
  {
    name: 'bar'
    pass: 'rab'
  }
]

Or another format is to insert a comma:

1
2
3
4
5
6
7

arr = [
  name: 'foo'
  pass: 'oof'
,
  name: 'bar'
  pass: 'rab'
]

In the spirit of CoffeeScript, we want to avoid using braces as much as possible. Therefore, the second method is preferred.