Ok, thanks for the clarification. I retract my "-1": no strong objections.
On Wed, Apr 22, 2020 at 3:15 PM Dmitriy Pavlov <dpav...@apache.org> wrote: > Hi Folks, > > There is nothing wrong with releasing system by it's modules, one-by-one. > Also it is perfectly OK to have each module in a separate git repo. Each of > these module release-candidate is voted separately. At the foundation > level, release cycle of the project/modules is not defined, it is up to the > community to decide. It is just general common sense: often releases are > preferred. > > The only one rule, community should vote on release with 3 +1 votes from > the PMC members. And there can be the only issue if module release would > stall without required number of binding votes. > > Sincerely, > Dmitriy Pavlov > > ср, 22 апр. 2020 г. в 15:03, Igor Sapego <isap...@apache.org>: > > > Pavel, > > > > 1. We can conduct separate votes for every client, do you see any issues > > here? > > 2. This is true, but we have backward compatibility in our protocol, so > > everything > > should work just fine. > > > > Best Regards, > > Igor > > > > > > On Tue, Apr 21, 2020 at 9:22 PM Pavel Tupitsyn <ptupit...@apache.org> > > wrote: > > > > > -1 > > > > > > - Ignite is a single Apache project, it follows Apache release > > guidelines, > > > with voting and so on. Not sure how are we going to follow that with a > > > separate repo. > > > - Thin client features are often tied to server-side changes > > > > > > > What about dotnet and cpp thin clients? > > > Those reuse some code with thick counterparts - same way as Java thin > > does. > > > > > > > > > On Tue, Apr 21, 2020 at 4:22 PM Nikolay Izhikov <nizhi...@apache.org> > > > wrote: > > > > > > > What about dotnet and cpp thin clients? > > > > > > > > > 21 апр. 2020 г., в 16:19, Dmitriy Pavlov <dpav...@apache.org> > > > > написал(а): > > > > > > > > > > +1 since > > > > > - Simpler release may allow us to release more often > > > > > - Often releases - users will get updates faster, more chances to > > grow > > > > and > > > > > keep our user base > > > > > - Faster updates and easy to get next update may have positive > effect > > > on > > > > > community growth. Since newcomer may want to fix a bug and later > use > > > > result > > > > > in his/her production environment. > > > > > > > > > > вт, 21 апр. 2020 г. в 13:27, Alexey Zinoviev < > zaleslaw....@gmail.com > > >: > > > > > > > > > >> Agree with these non-JVM languages. > > > > >> Especially for Python:) > > > > >> > > > > >> вт, 21 апр. 2020 г. в 12:58, Igor Sapego <isap...@apache.org>: > > > > >> > > > > >>> Guys, > > > > >>> > > > > >>> It was discussed on the dev list a few times that it would be a > > good > > > > >>> idea to move Python, Node.js and PHP thin clients to separate > repos > > > > >>> and separate release cycles. > > > > >>> > > > > >>> In short there are several arguments for that: > > > > >>> > > > > >>> 1. There are no dependencies on the core functionality so there > is > > > > simply > > > > >>> no need for them to be in the main repo. > > > > >>> > > > > >>> 2. Those thin clients often do not get updates from release to > > > release, > > > > >> but > > > > >>> still > > > > >>> we "release" them, as they are a part of the main release. > > > > >>> > > > > >>> 3. Moving them to a separate release cycle will allow us to > release > > > > some > > > > >>> hot > > > > >>> fixes for those clients faster and easier. > > > > >>> > > > > >>> 4. Composer needs a PHP packet that is released to be in a > separate > > > > >>> repository. > > > > >>> > > > > >>> Thoughts? > > > > >>> > > > > >>> Best Regards, > > > > >>> Igor > > > > >>> > > > > >> > > > > > > > > > > > > > >
