Piotr, I haven’t committed much to 3.x since June because it already has everything I set out to do. It is everyone else who keeps adding crap that “must” be done before it can be released. Yet another year is far too long. If that is the case my vote is to skip the additional stuff. And I will always be fine other oving things if they are no longer supportable or need to be separated into a new module so long as end user code doesn’t have to be changed.
Releases do not have to be perfect. In fact, someone advised me once that you don’t want them to be as that is how you draw in new committers. Ralph > On Nov 2, 2023, at 2:10 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi Ralph, > >> On Thu, 2 Nov 2023 at 09:42, Apache <ralph.go...@dslextreme.com> wrote: >> I’m confused. 3.0.0 hasn’t even been released so how can I be preventing >> adding anything. Personally I would prefer the monitoring to be in a >> separate repo but I am ok with adding it to the main build. IAM all for >> moving async out but unless it can be done quickly I’d rather do it in a >> future 3.x release. The same is generally true for your other bullets as >> well. > > What I meant: we can not **remove** anything after 3.0.0 GA is > released, this includes module refactorings. > I know that you are pushing hard to have a beta by the end of this > year and GA shortly after. > > The problem is: the development of 3.x has been stagnating since June. > Since then I have only seen Matt, Volkan and myself committing > something. > Since most of these changes can not be done in our day jobs, a more > realistic release date for 3.x is the end of the year 2024. > Right now the JLink project I added to Samples works with 2.x, but > **fails** with 3.x (besides, 3.x snapshots are not getting published > since a month and I don't have the faintest idea why). > > Piotr
