On Tue, May 6, 2025 at 5:17 PM ayoub mrini <ayoubmrini...@gmail.com> wrote:
> > If you mean building a single website that partly uses the old stack and > partly the new one, that would sound very painful to me (one is Ruby/nanoc, > the other one is JS, and they'd be very different in general). > > Yes, that’s what I meant, having one proxy to the other or having a > reverse proxy in front of them or linking them together at build time, > though I suspected it wouldn’t be easy to pull off. > Yeah, I don't think that'll be necessary. In my rebuild I'm starting with the hard part (the docs), and then the rest of the pages should be relatively easy. In any case, we can totally have the old and new landing page run completely separately on two different domains for a while though. > > Good question, probably not, that was released in 2017 :) If that got in > the way, we could probably remove it, but even with 2.x versions, we go > back over a year currently. > > Yes, I assumed we could only have versions from the current LTS onward > (which is 2.53 now) it there, given that 3.5 is the next LTS... but that > doesn’t really work I think. > I'm now going for a Next.js approach where I do the Markdown (not MDX) parsing myself vs. using their MDX integration which wouldn't have done what we need anyway. So I think that's gonna be fine, we can just stick with regular Markdown for now. > (Maybe LLMs can help with the conversions) > > On Friday, April 25, 2025 at 11:21:22 PM UTC+2 Julius Volz wrote: > >> On Fri, Apr 25, 2025 at 6:23 PM ayoub mrini <ayoubm...@gmail.com> wrote: >> >>> Thanks for the update Julius. >>> How about keeping both stacks for some time? the new one for the latest >>> version and the old one for the rest? Would this be easy to set >>> up/maintain? This way visitors can get a taste of both the old and new >>> worlds. >>> >> >> If you mean serving both a complete old website and a complete new >> website in parallel for a while, that would be easy to do as long as the >> Markdown content that feeds both sites can be made to work with both at the >> same time. If you mean building a single website that partly uses the old >> stack and partly the new one, that would sound very painful to me (one is >> Ruby/nanoc, the other one is JS, and they'd be very different in general). >> >> Or maybe we can fix the markdowns on `main` and add that MDX compiler in >>> the CI to avoid regressions and just wait until the old versions >>> "disappear"/become irrelevant and we can remove them? >>> >> >> I think then we'd effectively have to wait for years, so I think that's >> not a great option unfortunately. >> >> I see we still have `1.8` in there >>> https://prometheus.io/docs/prometheus/1.8/getting_started/, does that >>> still make sense? >>> >> >> Good question, probably not, that was released in 2017 :) If that got in >> the way, we could probably remove it, but even with 2.x versions, we go >> back over a year currently. >> >> Maybe an option is to start adjusting things in HEAD and then maintain >> manual Markdown->MDX patch sets for the older versions that are applied >> before the rest of the MDX pipeline. I'd have to play around with that a >> bit. >> >> >>> On Friday, April 25, 2025 at 2:27:25 PM UTC+2 Julius Volz wrote: >>> >>>> Just an update on this website revamp idea and why I haven't moved >>>> forward yet - of course after proposing it I started thinking about whether >>>> it would be much nicer to just immediately go for a complete >>>> reimplementation using a modern web stack. That brought up many issues to >>>> solve, but the main one is the following: most JS docs site builders these >>>> days expect MDX (Markdown with React-ish extensions) as an input format for >>>> docs pages, whereas we have plain Markdown pages that not only come from >>>> the current website repo, but also from historic branches of various >>>> releases of Prometheus and the Alertmanager. A lot of Markdown parses fine >>>> as MDX, but there are many constructs in our Markdowns that blow up the MDX >>>> compiler in my experiments (like `<string>` and stuff like that). If we >>>> only had current docs, that would be less of a problem (because we could >>>> just adjust things there), but if we need to pull in old versions of docs >>>> from other repos, then it's harder to solve. We'd either have to update the >>>> docs in all the old release branches or do some kind of >>>> pre-processing-patching on them to get rid of incompatibilities before >>>> using them as MDX. It would still be super nice to get rid of the old >>>> nanoc-based site at some point though. >>>> >>>> Anyway, I'm still thinking about this and how to best approach it :) >>>> >>>> On Fri, Sep 20, 2024 at 7:23 AM Julius Volz <juliu...@gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> The Prometheus homepage (prometheus.io) looks very dated by now, and >>>>> I wouldn't be surprised if it turns off a lot of first-time visitors >>>>> just by its looks. While I don't have the capacity to make this another >>>>> major project at the moment, in lieu of a more extensive docs & homepage >>>>> rework, what do people think about me just working to update the design of >>>>> the landing page to make it look at least slightly more modern? I was >>>>> thinking of this kind of direction (just a start): >>>>> >>>>> https://prometheus-new.netlify.app/ >>>>> >>>>> (user logos are blurry because many never provided us SVGs - this >>>>> would have to be fixed) >>>>> >>>>> This would mainly change the landing page, although of course the >>>>> fonts and a few styles would also have to be updated on other pages to >>>>> make >>>>> them consistent. But that should stay a minor change. >>>>> >>>>> I built the quick demo above using a more modern tech stack (Mantine, >>>>> React + JSX, etc.) than our homepage, but I could try to backport the same >>>>> styles to our old homepage framework with pure HTML + CSS. Eventually it >>>>> would be really nice to port the homepage to a less medieval static site >>>>> builder, but that's a much much larger project. >>>>> >>>>> Cheers, >>>>> Julius >>>>> >>>> -- >>> >> You received this message because you are subscribed to the Google Groups >>> "Prometheus Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to prometheus-devel...@googlegroups.com. >>> >> To view this discussion visit >>> https://groups.google.com/d/msgid/prometheus-developers/7c5f39d9-48ae-4851-ae9f-742092c25880n%40googlegroups.com >>> <https://groups.google.com/d/msgid/prometheus-developers/7c5f39d9-48ae-4851-ae9f-742092c25880n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "Prometheus Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to prometheus-developers+unsubscr...@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/prometheus-developers/e085d3e5-e663-4212-bd8e-c9da4a26531an%40googlegroups.com > <https://groups.google.com/d/msgid/prometheus-developers/e085d3e5-e663-4212-bd8e-c9da4a26531an%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YowaGJAv4zguhv1bqs6DQk%3DX_ORrf7G_JLqV5wwFY-sUQg%40mail.gmail.com.
