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?

[Trott]

This stalled. I'm going to close it. If someone else wants to pick it up and advocate for it, leave a comment, or re-open (if GitHub lets you), or open a new issue. Sorry/thanks.

[ljharb]

:-/ it stalled, but I have no idea why, nor what/who was missing to make progress on it. Any guidance?

[Trott]

@ljharb If you're willing to advocate, maybe the thing to do is put it back on the Build WG agenda and invite you as a guest. The last time it was on the agenda (in March), the minutes just say that the conversation should continue in GitHub. I don't think it's on anyone's radar. Having someone at the meeting who cares about it and can explain the value (and pitfalls) would probably help push it along, or at least document an explanation as to why it won't happen or isn't happening for now.

[ljharb]

That sounds great; please loop me in and I'll do my utmost to attend.

[rvagg]

FYI a lot of this naming stuff is hard-coded in Node's Makefile. Look for the bug DISTTYPE section which even includes "next-nightly" which we no longer use now. When I first got that in there I tried to make it more generic but during negotiation we ended up with a mid-way state where it's partly generic and partly hard-coded and it's been frustrating ever since.

The state we have now is that we have this awkward push and pull that goes on between Makefile, Jenkins and the promote scripts. In Jenkins we have this duplicated for each of the release build scripts (including a Windows variant):

RELEASE_URLBASE=https://nodejs.org/download/${disttype}/
if [ "X${disttype}" == "Xtest" ]; then
  disttype=custom
  CUSTOMTAG="test${datestring}${commit}"
  RELEASE_URLBASE=https://nodejs.org/download/test/
elif [ "X${disttype}" == "Xv8-canary" ]; then
  disttype=custom
  CUSTOMTAG="v8-canary${datestring}${commit}"
  RELEASE_URLBASE=https://nodejs.org/download/v8-canary/
elif [ "X${disttype}" == "Xrc" ]; then
  disttype=custom
  CUSTOMTAG="rc.$rc"
  RELEASE_URLBASE=https://nodejs.org/download/rc/
fi

i.e. we are overloading "custom" in Makefile to introduce these new types (test, v8-canary and rc), meanwhile Makefile handles "release", "nightly" and "next-nightly" (which we don't even use).

What I'd like to see is a complete overhaul of all of these 3 things, particularly yanking out that stuff in Makefile and replacing it with something much more simple and generic that we can bend to our will whenever we want to do something new, probably in Jenkins with some simple env vars. Having to get changes into nodejs/node to make this happen is pretty annoying and there's not a whole lot people confident enough to review Makefile changes anyway.

While we're at it we can fix the long-standing release-only problem we have in Makefile which checks for REPLACEME. We have a perl -pi -e "s/: release-only/:/g" Makefile hard-wired in Jenkins for everything but release builds because it gets in the way every time someone wants to make a non-release build (rc builds in particular)!

[mhdawson]

@ljharb can you make the next meeting on 6th of February at 4EST ?

[ljharb]

@mhdawson absolutely; please add my gmail to the meeting and I'll calendar it.

[ljharb]

Per the WG meeting, @nodejs/version-management will come up with a concrete proposal, and will bring it back to interested parties.

[Trott]

I'm inclined to close this until a concrete proposal comes back. If anyone thinks that's A Bad Idea, feel free to re-open or leave a comment here requesting that this be re-opened.