0
0
mirror of https://github.com/nodejs/node.git synced 2024-11-29 23:16:30 +01:00
nodejs/doc/blog
isaacs 3b2e9d2648 stream: remove lowWaterMark feature
It seems like a good idea on the face of it, but lowWaterMarks are
actually not useful, and in practice should always be set to zero.

It would be worthwhile for writers if we actually did some kind of
writev() type of thing, but actually this just delays calling write()
and the overhead of doing a bunch of Buffer copies is not worth the
slight benefit of calling write() fewer times.
2013-02-21 15:23:18 -08:00
..
feature stream: remove lowWaterMark feature 2013-02-21 15:23:18 -08:00
module blog: Remove all windows line endings once and for all 2012-08-01 10:14:17 -07:00
npm blog: Forgot slug on peer-dependencies article 2013-02-12 16:30:25 -08:00
release Merge remote-tracking branch 'ry/v0.8' into master 2013-02-18 10:21:08 -08:00
Uncategorized website: typo fixes 2012-11-29 23:00:09 +01:00
video blog: s/LibUV/libuv/ 2012-09-30 15:47:27 -07:00
vulnerability doc: don't use ' 2012-09-04 21:15:39 +02:00
README.md website: typo fixes 2012-11-29 23:00:09 +01:00
v0.9.9.md blog: v0.9.9 is unstable, not stable 2013-02-07 10:35:35 -08:00

title: README.md status: private

How This Blog Works

Each .md file in this folder structure is a blog post. It has a few headers and a markdown body. (HTML is allowed in the body as well.)

The relevant headers are:

  1. title
  2. author
  3. status: Only posts with a status of "publish" are published.
  4. category: The "release" category is treated a bit specially.
  5. version: Only relevant for "release" category.
  6. date
  7. slug: The bit that goes on the url. Must be unique, will be generated from the title and date if missing.

Posts in the "release" category are only shown in the main lists when they are the most recent release for that version family. The stable branch supersedes its unstable counterpart, so the presence of a 0.8.2 release notice will cause 0.7.10 to be hidden, but 0.6.19 would be unaffected.

The folder structure in the blog source does not matter. Organize files here however makes sense. The metadata will be sorted out in the build later.