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]

Reply via email to