singhvishalkr commented on PR #1123:
URL: https://github.com/apache/pulsar-site/pull/1123#issuecomment-4295380835
Thanks for the review @lhotari! Before I push the reshape I wanted to flag
what the dist layout actually exposes for each client, so the final table
matches reality:
| Client | Binary archive at `archive.apache.org/dist` | Source archive |
Versioned release notes under `release-notes/versioned/` |
|---|---|---|---|
| C++ | none (no RPM/DEB in the tree; some versions ship
`apache-pulsar-client-cpp-${v}.tar.gz` only) |
`apache-pulsar-client-cpp-${v}.tar.gz` | **yes** (`client-cpp-*.md` exists) |
| Go | none | `apache-pulsar-client-go-${v}-src.tar.gz` | no (release notes
live on GitHub releases) |
| Node | `napi-*` prebuilts per platform (darwin/linux/win, arm64/x64,
glibc/musl) plus a source tarball | `apache-pulsar-client-node-${v}.tar.gz` |
no (GitHub releases) |
| Python | none on dist (wheels ship on PyPI, not ASF) |
`pulsar-client-python-${v}.tar.gz` | **yes** (`client-python-*.md` exists) |
Given that, two shapes make sense -- happy to ship whichever you prefer:
**Option A** -- reuse `OldReleaseTable` verbatim with 4 columns: `Release |
Binary | Source | Release Notes`.
- C++ + Python: leave Binary empty, point Source at the tarball, link
Release Notes to the versioned page.
- Go: leave Binary empty, point Source at the `-src.tar.gz`, point Release
Notes at `https://github.com/apache/pulsar-client-go/releases/tag/v${v}`.
- Node: point Binary at the source tarball *and* summarise napi prebuilts in
a footnote (or a nested disclosure link), Source at the same tarball, Release
Notes at `https://github.com/apache/pulsar-client-node/releases/tag/v${v}`.
Node is the only client where "Binary" has a real meaning on dist, but it's N
platform-specific rows, not one.
**Option B** -- extend the current `ReleaseTable` to also carry a
`releaseNote` column; keep a single "Download" column because 3 of the 4
clients are source-only anyway, so a "Binary" column would be empty for them.
My lean is **Option A** -- it keeps the page visually consistent with "Older
releases" above, which is what you asked for -- with Node handled by linking to
`napi-*` listings in a sub-line. Want me to go with A and submit, or do you
prefer the B path?
Either way, would you like me to keep the existing one-line bug fix (tarball
instead of directory) in this PR or split it out as a smaller prior PR so the
reshape lands cleanly?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]