> it [doesn't] fully documents what was in prior releases Why is this a problem? We document newly added features with "starting from version X, Log4j ships Y...". Doesn't this address your concern?
Many projects follow this convention, even Java itself: https://docs.oracle.com/en/java/javase/index.html I think we can perfectly make it work for us too. Plus, we provide no public links to previous releases. That is, we provide no links nowhere to `logging.apache.org/log4j/log4j-2.19.0`, hence, it is practically hidden. As a matter of fact the following command returns empty on `asf-site` branch of `logging-log4j-site` repository: find . -type f -not -path "*/.git/*" -and -not -path "*/log4j-2.19.0/*" | grep log4j-2.19.0 This proves we don't link `log4j-2.19.0` anywhere. (Please correct me if I am wrong.) On Mon, Oct 23, 2023 at 10:10 AM Apache <ralph.go...@dslextreme.com> wrote: > I am ok with 1 and 2, but not 3. Doing that means older releases web sites > are no longer available. Just because the latest includes release notes for > all versions doesn’t mean it fully documents what was in prior releases. > However, I am not surprised you are suggesting this as I posted in an > earlier email that CI of the web site would be difficult due to this. > > Ralph > > > On Oct 22, 2023, at 2:03 PM, Piotr P. Karwasz <piotr.karw...@gmail.com> > wrote: > > > > Hi Volkan, > > > >> On Sun, 22 Oct 2023 at 22:20, Volkan Yazıcı <vol...@yazi.ci> wrote: > >> 3. *Don't create a new folder for every release, but override the > `2.x` > >> folder.* > >> - This is okay, since we keep backward compatibility in minor+patch > >> releases and explicitly provide version for features that are > added later > >> on (e.g., "starting from 2.17.0 Log4j provides X...") > >> - We can set up CI jobs to periodically populate `1.x`, `2.x`, > `3.x`, > >> `4.x`, etc. websites and avoid the need to generate the website > once and > >> for all. > >> - We will stop polluting the folder structure. > > > > +1 on keeping just `1.x`, `2.x`, etc. > > > > We just need to keep in mind that not all public methods have a > > correct `@since` Javadoc tag. We would need to fix that. > > > > Piotr > >
