jorisvandenbossche commented on issue #44887:
URL: https://github.com/apache/arrow/issues/44887#issuecomment-2508963176

   > do you remember what the idea was behind your change in 
[8963755](https://github.com/apache/arrow/commit/8963755f5174a5aae363a4828c0e1992febaa141)?
 To fix the problem in this issue, I'm considering removing all the major/minor 
parts of the script.
   
   That change was certainly not made to properly deal with "minor" releases 
(as in `major.minor.patch`, and at the time we only ever did major or patch 
releases), so the major / minor is maybe a confusing naming, but with the 
current set-up I think the script still needs to distinguish major+minor vs 
patch releases.
   
   Right now, IIRC, the workflow goes like this:
   
   - The latest released ("stable") version of the docs lives at the root of 
`https://arrow.apache.org/docs`, and then previous versions e.g. at 
`/docs/18.0/`
   - When we make a new non-patch (major/minor) release -> at this point the 
current stable docs are copied to its versioned subdirectory, and then the docs 
of the new release are written over the old stable docs at the root of the 
`/docs` folder.
   - When we make a patch release, only the stable docs at the root need to be 
overwritten with the new docs, as we don't keep separate docs of patch releases 
of the same major/minor release (e.g. of 15.0.0, 15.0.1 and 15.0.2)
   
   Now, I do think it would probably be an improvement/simplification to 
already make the versioned subdirectory at the time of making the release (e.g 
now for 18.1.0, already make the `docs/18.1/` directory), and do when doing the 
release just copy the new docs to two places (versioned subdir and root), then 
we don't have to this "move current stable docs to subdir".
   
   ---
   
   This is all with the presumption that we indeed don't want to keep the docs 
of every single version. I personally still think that is better, because 1) 
there is typically hardly a difference between those, 2) it reduces the size of 
the docs, and 3) I also wouldn't want to include those in the version dropdown 
anyway because it would just be unnecessary noise to the user of the docs.
   
   (personally, with the way we currently make minor releases like 18.1.0 as 
just a bit extended patch release, I would even argue the same for those, and 
just keep one version of the docs for the entire 18.x release cycle)


-- 
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