Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

have two channels for the website #808

Open
amtoine opened this issue Mar 6, 2023 · 5 comments
Open

have two channels for the website #808

amtoine opened this issue Mar 6, 2023 · 5 comments

Comments

@amtoine
Copy link
Member

amtoine commented Mar 6, 2023

as the following PR has been closed

i've been thinking about something that could be cool to allow

  • probably the major part to enjoy a stable experience when looking at the website
  • people like me who build nushell from source almost everyday to have access to bleeding edge documentation

❔ could it be possible to have two parallel channels for the website?

  • ⚖️ the default one would build the final HTML pages based on the latest stable tag
  • 🩸 the other one could be toggled on or off and would show up the latest main

implications

  • ⚖️ tag this repo once in a while when the version is bumped up
  • 🩸 people could, after a documentation-changing PR over in the main nushell, apply the changes here with a single nu make_docs.nu and link to the associated nushell PR for completeness

what do you think? 😋 👋

@fdncred
Copy link
Contributor

fdncred commented Mar 6, 2023

just for my two cents, i find it hard enough to keep one site up to date. so, i wouldn't be in favor of two unless we had a maintainer who was dedicated to keeping both running and up to date.

@amtoine
Copy link
Member Author

amtoine commented Mar 7, 2023

just for my two cents, i find it hard enough to keep one site up to date. so, i wouldn't be in favor of two unless we had a maintainer who was dedicated to keeping both running and up to date.

yep, of course, that is a very good point and a legitimate concern 🤔

in order to make a proper decision, what would such a maintainer have to do precisely to achieve this? 😋

@sholderbach
Copy link
Member

I have to admit that I don't really see the point having a separate documentation for the "nightly" version of what is on the main branch on nushell/nushell at the moment. The command docs should be accessible through help and long-form writing will always require extra work from the contributors and might take a few days to arrive separate from the implementation PR. Making this more complicated just reduces the chance that people contribute to the core docs.

Where I can see value in the extra work of adding extra channels on the page: If we would be to be able to have documentation in the state of specific version. When we get more and more serious users while still not being stable, people might choose to stay behind for a bit on a specific version. They might be interested in the rules and command semantics at their particular release. While it is not really scalable to provide active support (thorough replies in issues, contributors helping out in discord) for people behind the curve having the docs for passive support would probably go a long way. (also interesting as a time capsule for implementers)

@rgwood
Copy link
Contributor

rgwood commented Mar 8, 2023

I don't think that this is worth the effort right now. It would make the website substantially more complicated, and the potential audience would be very small (people who build from main and primarily use the website instead of help).

Could be worthwhile after v1.0 though.

@amtoine
Copy link
Member Author

amtoine commented Mar 8, 2023

thanks a lot for all your feedback, very sensible things going on here 😌

@sholderbach

Where I can see value in the extra work of adding extra channels on the page: If we would be to be able to have documentation in the state of specific version. When we get more and more serious users while still not being stable, people might choose to stay behind for a bit on a specific version. They might be interested in the rules and command semantics at their particular release. While it is not really scalable to provide active support (thorough replies in issues, contributors helping out in discord) for people behind the curve having the docs for passive support would probably go a long way. (also interesting as a time capsule for implementers)

so do you mean having one version of the website per release? for the 0.76.1, 0.76.0, ...?

@rgwood

I don't think that this is worth the effort right now. It would make the website substantially more complicated, and the potential audience would be very small (people who build from main and primarily use the website instead of help).

yep that's not my case, i just felt a bit sorry for the website to lag behind the latest main 😋

Could be worthwhile after v1.0 though.

your call 😉

in the end guys

  • if you feel this is not worth it, you can close the issue
  • if you feel effort could be great in the direction of @sholderbach or that it can wait after the 1.0 as suggested by @rgwood, you can also leave it open

cheers 👋 😊

ayax79 pushed a commit to ayax79/nushell.github.io that referenced this issue Jun 26, 2024
This adds a little command that allows opening .env files as records.
My implementation removes comments and works with both quoted and
unquoted .env files.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants