Hi Daniel, Both topics are non-blocking in my opinion
Regarding documentation: A complete Maven website including Markdown content is generated. And documentation will be updated, extended and moved to Docbook but that can be done any time - no need to introduce additional dependencies Regarding backward compatibility: * The code is mostly written by one person and that's me - so it is not a mature code base * There are hardly any users out there and new user will detect bugs, suggest improvements or will tell you that some parts are simply broken by design - enforcing backward compatibility will do some harm here * I consider backward compatibility important assuming that you HAVE many users out there * It is a command-line tools mostly used by developers and they know what a 0.x release means - some things are in motion and need time to settle Thanks in advance, Siegfried Goeschl > On 24.10.2021, at 15:16, Daniel Dekany <daniel.dek...@gmail.com> wrote: > > Yes, I guess we can get away with the Maven generated site, if the standard > ASF footer and that conference ad thingy can be added. It would be more > rational to push through with the conversion to DocBook though. The main > cause of the slowdown is that I had this idea that we actually run > everything that we show, and never copy-paste sources and output. That was > proven to be tricky in many cases, and is still unsolved in some (like > where the example uses Linux shell features). I should just let that go for > now and push through with the conversion with copy-pasting where we still > have problems. On that note, I wonder if you want to rework the content > anyway, like we want to move most examples outside the documentation, and > then people can open them in IDE, modify them to play around, etc. If you > do such reworking, or any serious reworking really, that should be already > done in DocBook. > > The warning about no backward compatibility needs to be apparent from > whatever documentation we release (the DocBook version has it). Backward > compatibility is really the main pain with the release. As we promise not > backward compatibility, we basically release software without promising > later support. People can still decide to use it (or they just don't > realize what this means). But, you may feel pressure to keep backward > compatibility instead of doing the right thing, which at this stage is > maybe not wise. (Also no support can be tricky when there's a security > issue with an old release. Although that's probably less relevant for a > tool like this.) > > On Sun, Oct 24, 2021 at 1:02 PM Siegfried Goeschl < > siegfried.goes...@gmail.com> wrote: > >> Hi Daniel, >> >> There is still the Maven-based site which can be created using >> >>> mvn clean site site:stage >> >> I will look into the source release packages ... >> >> Thanks in advance, >> >> Siegfried Goeschl >> >> >>> On 24.10.2021, at 11:38, Daniel Dekany <daniel.dek...@gmail.com> wrote: >>> >>> Still no site for example. Note sure about the others, had to review last >>> time's list. >>> >>> Can we build a source release package with all the necessary >>> NOTICE-s/LICENSE-s and signing? For this kind of project we will also >> want >>> a binary release package. >>> >>> On Sat, Oct 23, 2021 at 6:59 PM Siegfried Goeschl < >>> siegfried.goes...@gmail.com> wrote: >>> >>>> Hi folks, >>>> >>>> What stops us from having the first release? Any blockers we are aware >> of? >>>> >>>> Thanks in advance, >>>> >>>> Siegfried Goeschl >>>> >>>> >>>> >>>> >>> >>> -- >>> Best regards, >>> Daniel Dekany >> >> > > -- > Best regards, > Daniel Dekany
