For me, holding a significant (years) window of docs/releases on the site and then clearing out things beyond that every so often is reasonable for a variety of reasons.
It leaves the more recent docs/releases we might expect people are likely to be using available on the site, which is good for them and for us, but it removes multiple-years-old things that we wouldnt reasonably expect or want anyone to be using where much newer releases exist, and the project doesnt really support anymore anyway. Updating the site helps make that all clearer and the bits can ultimately still always be found in the archive if really needed, which the site would still note. It also helps keep the site content in check both for the space it is using on the web servers and on developer machines. The source for the site is currently ~2.5GB with a rather large number of files (which is probably as impactful rather than just the size alone). With git metadata and build output etc you need 6GB+ to actually work on it. In itself thats not too bad, yes I can also fit it on my phone, but multiply that kind of size by the number of different projects which the foundation has or that individual people work on, and it all starts to add up to much bigger numbers and points where it is actually something worth keeping in check. It also helps keep the build from getting ever slower for those few actually working on updating the site regularly, both locally when working on updates and later for the actual live update on push. The CI build now 'only' takes ~3 minutes to update the site on push thanks to the faster env that job moved to at some point, but it used to take 6+ minutes not that long ago. I'm not sure how workable the 'dont build bits to speed things up' idea is with the way the site works, especially the actual remote build that updates the content for the webserver, where it replaces and compares the output of the checked-in output branch to decide what output updates there were that it now needs to check in and deploy. Regardless, I think its just simplest all round to just keep the build in check by removing the really-pretty-old stuff that few should be looking at. On Sat, 7 May 2022 at 05:46, Michael André Pearce <michael.andre.pea...@me.com.invalid> wrote: > > What harm is there in keeping old docs? I’m a little -1 removal of old docs > unless there’s areal pressing driver that cannot be addressed / resolved. > > E.g. what is the driver here? > > Space on the http server? I’d be a bit surprised if it was due to this docs > aren’t that huge, and in this day and age even my mobile probably can store > all historical docs fine…. > > If it’s build time of website, can old docs not be generated once and marked > to not rebuild for website rebuild by default, probably want to have a flag > to force a rebuild if really needed… > > > > > Sent from my iPad > > > On 6 May 2022, at 14:12, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > > > > I think that can have its own issues in terms of most easily (for us > > and them) directing folks to the appropriate bit of doc when answering > > a question, given how often users love to ask questions about > > not-latest versions. I've found maintaining a window of docs to be a > > good balance. > > > > E.g consider that you just change the default of some values; having > > only the current docs will likely mislead other people on the > > behaviour. Sometimes even those that wrote it, because they forgot, > > and are looking at the doc to find out what it does :) > > > >> On Fri, 6 May 2022 at 13:26, Clebert Suconic <clebert.suco...@gmail.com> > >> wrote: > >> > >> I would prefer only keeping the current doc... older docs are part of > >> the zip bundle anyways, right? > >> > >>> On Fri, May 6, 2022 at 7:02 AM Robbie Gemmell <robbie.gemm...@gmail.com> > >>> wrote: > >>> > >>> I think it is reasonable to remove older docs, both to control the > >>> size of the site content and since people should be using the more > >>> recent things already. > >>> > >>> For Qpid the main docs page links to the current docs, and links to > >>> the 'past releases' page where each release page then has that > >>> versions docs. We typically keep the last 2-3 years of the release > >>> specific pages/download links/docs etc available on the site. > >>> Infrequently we then trim the oldest ones out to get back nearer the 2 > >>> years. Rinse and repeat. Link to the archive for anything not on the > >>> site. > >>> > >>> On Fri, 6 May 2022 at 02:51, Clebert Suconic <clebert.suco...@gmail.com> > >>> wrote: > >>>> > >>>> Can we stop storing old releases documentation on the website? > >>>> > >>>> > >>>> If we start to release bi weekly as we proposed, it's going to be a > >>>> lot of old releases in there. > >>>> > >>>> Over the years this has accumulated a few already > >>>> > >>>> > >>>> https://activemq.apache.org/components/artemis/documentation/ > >>>> > >>>> > >>>> > >>>> If users want a previous doc, they can always just download the older > >>>> version with the docs anyway. > >>>> > >>>> > >>>> > >>>> -- > >>>> Clebert Suconic > >> > >> > >> > >> -- > >> Clebert Suconic
