Skip to content
This repository has been archived by the owner on Mar 25, 2018. It is now read-only.

Document which node-versions are maintained currently #74

Open
robertkowalski opened this issue Feb 2, 2015 · 4 comments
Open

Document which node-versions are maintained currently #74

robertkowalski opened this issue Feb 2, 2015 · 4 comments

Comments

@robertkowalski
Copy link
Contributor

from: https://github.com/joyent/node-website/pull/72/files#r23943271

  • do we have some informations regarding that in the repo?
@misterdjules
Copy link

Not that I know of. Currently, the official stance is (taken from my answer to a post in the Node.js Google group):

The current policy is to do critical releases for as far back as can be supported (including v0.8 if needed). However, v0.8 is considered as being at end of life now, and for instance users should handle OpenSSL upgrades themselves. When v0.12 is released, v0.10 will be in maintenance mode.

That would mean that currently, only node v0.10.x is under maintenance. node v0.8.x is not under maintenance anymore but gets "critical" bug fixes nonetheless. The concept of what is critical and what is not seems a bit fuzzy though.

When node 0.12.x is released, both node v0.10.x and node v0.12.x will be under maintenance.

@tjfontaine Could you please confirm?

@robertkowalski
Copy link
Contributor Author

if not, we could alter https://github.com/joyent/node-website/blob/master/STABLE - that file gets generated in https://github.com/joyent/node/blob/master/tools/node-release-post-build.sh#L61 ... proposal in pseudo-code:

getpreviousstablenodeversion.py:

if current_version % 2
  return current_version - 2
else 
  return current_version - 1

then and using these two in node-release-post-build.sh would create this STABLE-file for 0.13 (current master):

0.10.36
0.8

based on that we could insert the information into the website

@misterdjules
Copy link

If I understand correctly, the STABLE file is only updated when a "stable" release is done, so the previous stable release should always (at least as long as the even/odd stable/unstable naming convention for releases is used) be current_stable_major - 2.

Also, I think we would want to have the full version number of the previous stable release and not just major.minor (in your previous example, we would have 0.8.29 instead of just 0.8).

@misterdjules
Copy link

We would also need to handle the update of the STABLE file when a new release is done for the oldest maintained version(s) (v0.8.x currently, but v0.10.x after node v0.12.0 is released).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants