file and directory names for downloads

[Trott]

Let's revisit the file naming and redirects for the downloads directory in an effort to hopefully set users up for maximum future success.

Some things to note:

• We used to call them RCs. They used to end up in a rc directory with a -rc suffix. The problem: They weren't RCs. So we renamed them beta. Hooray! But they ended up in a test directory. What? Boo!
• Aside from being semantically confusing for end users, and possibly more importantly, this has implications for nvm.

/cc @ljharb for nvm implications and what would be ideal if nvm were to support betas. (What symlink/redirect stuff would be required? How would the directory/filename layout look ideally. That sort of thing.)

/cc @jasnell as this would affect releases...

It would be great if as much relevant information as possible were put here, of course. But also, when we discuss this at a Build WG meeting (if that is necessary, which I suspect it will be if we want to move on this quickly), it would be great if we could arrange to make sure that both @ljharb and @jasnell could be there.

[jbergstroem]

Lets try and put forward something to discuss at that meeting; for instance a suggestion on how we want it to be? This needs to be streamlined with our jenkins config as well as Makefile. Likely also ported back to at least some branches.

[MylesBorins]

so I think we need

• beta (ongoing build with moving changes)
  • labelled -beta.#
• rc (pre releases that are not subject to changes except when neccessary)
  • labelled -rc.#
• test (test releases being build for a variety of reasons)
  • labelled -test-$DATE
• nightly (automated releases)
  • • labelled -nightly-$DATE

and of course release

thoughts?

[Trott]

@thealphanerd Especially if nvm is cool with all that, we could just start using something like that now and accept the fact that there are mis-labeled binaries in the past. I personally imagine that is acceptable, as it is probably pretty unusual for someone to want an rc or a beta from a year ago. So as long as the current ones are labeled correctly, everything is great.

[MylesBorins]

I think it would be valuable to agree to the release process on this and document it... then stick to it

/cc @nodejs/release

[jbergstroem]

From ci-release point of view we also have custom builds (which is sort of abused atm) to generate from other branches.

[ljharb]

My ideal scenario, whatever terminology we decide, would be one where the directory name and filename suffix were in sync, and were updated historically for all previous releases that had RCs (using symlinks on the server for this is an implementation detail, and fine)

I'm also fine with "RC", "beta", "test", and "nightly" - four branches theoretically is no harder than two, especially if they're consistent across both io.js and node versions.

While it might be unusual for someone to want old RCs etc, I think the continuity is important both for my testing, and to allow for 100% phaseout of any older terminology.

[Trott]

While it might be unusual for someone to want old RCs etc, I think the continuity is important both for my testing, and to allow for 100% phaseout of any older terminology.

I guess the problem is what to do about (for example) old "RCs". OK, so we can symlink or whatever and have them called betas instead. But we can't break the existing URLs for the files that contain an "rc" directory and an "rc" suffix. So they will forever be non-RC RC releases that are available. Maybe I'm overthinking it and that's just not a problem. Like, hey, it's available as an RC and a beta and it's the same thing and that's just a historical quirk, so deal with it if you're one of the three people who will be affected by that? I'm not sure.

[ljharb]

I don't think it will be a problem, especially if most people end up using nvm to install these things anyways.

You could always include a README in the old directories that explains the change, and that these are deprecated?