Re: Thin clients release cycle

[Yakov Zhdanov]

Guys, has anybody checked with INFRA if we can have module structure? Denis?

--Yakov

Re: Thin clients release cycle

[Pavel Petroshenko]

>From our point of view option (3) makes the most sense (if it works for the
ASF, as Denis pointed out).
Option (2) implies too much overhead, which may not be worth it.
(1) is the least convenient approach for such independent projects as
Client libs, however it's clear where it comes from. So it is what it is...

Regards,
Pavel


On Fri, Apr 6, 2018 at 2:22 PM, Denis Magda  wrote:

> Regardless of the path taken, the sources have to be located in ASF
> repositories since we agreed to contribute the clients to the Foundation.
>
> Presently, I'm leaning towards the monolithic approach (1) because that's
> just simpler for an ASF project.
>
> The hybrid way (3.) can work out only if ASF INFRA is ok with that.
> Otherwise, we need to get a permit to host many ignite-...-client projects
> separately. It's unlikely our ASF mates approve that. The reason is weak.
>
> --
> Denis
>
> On Fri, Apr 6, 2018 at 11:32 AM, Pavel Tupitsyn 
> wrote:
>
> > Vladimir, can you clarify your ideas from Apache projects standpoint?
> >
> > Do you propose (1) to create new apache projects for every client (or for
> > all of them)
> > Or (2) move thin clients OUT of Apache ecosystem and simply host them on
> > Github?
> >
> > I think none of these will fly with ASF.
> > I am strongly for Monolith and following ASF guidelines and releases.
> >
> > We can increase release frequency if you want to be "agile".
> >
> > Thanks,
> > Pavel
> >
> > On Fri, Apr 6, 2018 at 4:49 PM, Petr Ivanov  wrote:
> >
> > > I would vote for single repository and the following release scheme: we
> > > build and release everything, but deliver only that modules, which have
> > > actual features / bugfixes, skipping other from release iteration until
> > new
> > > changes come into them.
> > >
> > > Also, I’d propose versioning scheme, that will reflect Apache Ignite’s
> > > compatibility, i.e. if thin client requires features from Apache Ignite
> > > 2.4, then it’s own version will be 2.4.A.B (where A - own major
> version,
> > > that will be reset every new Apache Release, B - minor/fix version for
> > > minor / quick fixes goals that will be reset every new A version).
> > >
> > >
> > >
> > > > On 6 Apr 2018, at 16:15, Vladimir Ozerov 
> wrote:
> > > >
> > > > Igniters,
> > > >
> > > > Over the last year we saw dramatic increase in demand for lightweight
> > > thin
> > > > clients. We already have four: JDBC, ODBC, .NET, Java. In future we
> are
> > > > going to have even more: NodeJS, PHP, Python, Go, whatever. I'd like
> to
> > > > start a discussion on how are we going to host them. There are
> several
> > > > approaches.
> > > >
> > > > 1) *Monolith* - everything is hosted in a single repository and
> > released
> > > as
> > > > a single artifact. This is our current approach.
> > > >
> > > > Pros:
> > > > - Easy to manage
> > > > Cons
> > > > - Long release cycle
> > > > - Client features must be developed in sync with each other which
> would
> > > be
> > > > very hard should we have > 5-6 different clients:
> > > >
> > > > 2) *Modules* - clients are moved to separate repositories with their
> > own
> > > > release cycles. JDBC is released separately, ODBC separately, .NET
> > > > separately, Java (guess what?) - separately, etc..They could have
> > > different
> > > > timelines, different feature sets, different release notes, different
> > > > versions. This is natural approach employed by multitude of vendors.
> > > When
> > > > new feature is added we do not need to wait for Apache Ignite
> release.
> > > > Instead, we release only small client on it's own.
> > > > Pros:
> > > > - Fast and (sorry) agile release cycle!
> > > > - No need to wait for months for new Ignite version
> > > > - No need to sync features between different clients
> > > > Cons:
> > > > - More votes, more artifacts, more release-related code and scripts
> > > >
> > > > 3) *Hybrid* - all clients are hosted in a single separate repository
> > and
> > > > released in sync with each other, but not with Apache Ignite.
> Balanced
> > > mix
> > > > of pros/cons from #1 and #2 approaches.
> > > > Pros:
> > > > - Relatively fast release cycle
> > > > Cons:
> > > > - Still need to sync features between clients
> > > >
> > > > I think that we should start moving our clients to #2 or #3
> approaches
> > to
> > > > get greater momentum from community, What do you think?
> > > >
> > > > Vladimir.
> > >
> > >
> >
>

Re: Thin clients release cycle

[Denis Magda]

Regardless of the path taken, the sources have to be located in ASF
repositories since we agreed to contribute the clients to the Foundation.

Presently, I'm leaning towards the monolithic approach (1) because that's
just simpler for an ASF project.

The hybrid way (3.) can work out only if ASF INFRA is ok with that.
Otherwise, we need to get a permit to host many ignite-...-client projects
separately. It's unlikely our ASF mates approve that. The reason is weak.

--
Denis

On Fri, Apr 6, 2018 at 11:32 AM, Pavel Tupitsyn 
wrote:

> Vladimir, can you clarify your ideas from Apache projects standpoint?
>
> Do you propose (1) to create new apache projects for every client (or for
> all of them)
> Or (2) move thin clients OUT of Apache ecosystem and simply host them on
> Github?
>
> I think none of these will fly with ASF.
> I am strongly for Monolith and following ASF guidelines and releases.
>
> We can increase release frequency if you want to be "agile".
>
> Thanks,
> Pavel
>
> On Fri, Apr 6, 2018 at 4:49 PM, Petr Ivanov  wrote:
>
> > I would vote for single repository and the following release scheme: we
> > build and release everything, but deliver only that modules, which have
> > actual features / bugfixes, skipping other from release iteration until
> new
> > changes come into them.
> >
> > Also, I’d propose versioning scheme, that will reflect Apache Ignite’s
> > compatibility, i.e. if thin client requires features from Apache Ignite
> > 2.4, then it’s own version will be 2.4.A.B (where A - own major version,
> > that will be reset every new Apache Release, B - minor/fix version for
> > minor / quick fixes goals that will be reset every new A version).
> >
> >
> >
> > > On 6 Apr 2018, at 16:15, Vladimir Ozerov  wrote:
> > >
> > > Igniters,
> > >
> > > Over the last year we saw dramatic increase in demand for lightweight
> > thin
> > > clients. We already have four: JDBC, ODBC, .NET, Java. In future we are
> > > going to have even more: NodeJS, PHP, Python, Go, whatever. I'd like to
> > > start a discussion on how are we going to host them. There are several
> > > approaches.
> > >
> > > 1) *Monolith* - everything is hosted in a single repository and
> released
> > as
> > > a single artifact. This is our current approach.
> > >
> > > Pros:
> > > - Easy to manage
> > > Cons
> > > - Long release cycle
> > > - Client features must be developed in sync with each other which would
> > be
> > > very hard should we have > 5-6 different clients:
> > >
> > > 2) *Modules* - clients are moved to separate repositories with their
> own
> > > release cycles. JDBC is released separately, ODBC separately, .NET
> > > separately, Java (guess what?) - separately, etc..They could have
> > different
> > > timelines, different feature sets, different release notes, different
> > > versions. This is natural approach employed by multitude of vendors.
> > When
> > > new feature is added we do not need to wait for Apache Ignite release.
> > > Instead, we release only small client on it's own.
> > > Pros:
> > > - Fast and (sorry) agile release cycle!
> > > - No need to wait for months for new Ignite version
> > > - No need to sync features between different clients
> > > Cons:
> > > - More votes, more artifacts, more release-related code and scripts
> > >
> > > 3) *Hybrid* - all clients are hosted in a single separate repository
> and
> > > released in sync with each other, but not with Apache Ignite. Balanced
> > mix
> > > of pros/cons from #1 and #2 approaches.
> > > Pros:
> > > - Relatively fast release cycle
> > > Cons:
> > > - Still need to sync features between clients
> > >
> > > I think that we should start moving our clients to #2 or #3 approaches
> to
> > > get greater momentum from community, What do you think?
> > >
> > > Vladimir.
> >
> >
>

Re: Thin clients release cycle

[Pavel Tupitsyn]

Vladimir, can you clarify your ideas from Apache projects standpoint?

Do you propose (1) to create new apache projects for every client (or for
all of them)
Or (2) move thin clients OUT of Apache ecosystem and simply host them on
Github?

I think none of these will fly with ASF.
I am strongly for Monolith and following ASF guidelines and releases.

We can increase release frequency if you want to be "agile".

Thanks,
Pavel

On Fri, Apr 6, 2018 at 4:49 PM, Petr Ivanov  wrote:

> I would vote for single repository and the following release scheme: we
> build and release everything, but deliver only that modules, which have
> actual features / bugfixes, skipping other from release iteration until new
> changes come into them.
>
> Also, I’d propose versioning scheme, that will reflect Apache Ignite’s
> compatibility, i.e. if thin client requires features from Apache Ignite
> 2.4, then it’s own version will be 2.4.A.B (where A - own major version,
> that will be reset every new Apache Release, B - minor/fix version for
> minor / quick fixes goals that will be reset every new A version).
>
>
>
> > On 6 Apr 2018, at 16:15, Vladimir Ozerov  wrote:
> >
> > Igniters,
> >
> > Over the last year we saw dramatic increase in demand for lightweight
> thin
> > clients. We already have four: JDBC, ODBC, .NET, Java. In future we are
> > going to have even more: NodeJS, PHP, Python, Go, whatever. I'd like to
> > start a discussion on how are we going to host them. There are several
> > approaches.
> >
> > 1) *Monolith* - everything is hosted in a single repository and released
> as
> > a single artifact. This is our current approach.
> >
> > Pros:
> > - Easy to manage
> > Cons
> > - Long release cycle
> > - Client features must be developed in sync with each other which would
> be
> > very hard should we have > 5-6 different clients:
> >
> > 2) *Modules* - clients are moved to separate repositories with their own
> > release cycles. JDBC is released separately, ODBC separately, .NET
> > separately, Java (guess what?) - separately, etc..They could have
> different
> > timelines, different feature sets, different release notes, different
> > versions. This is natural approach employed by multitude of vendors.
> When
> > new feature is added we do not need to wait for Apache Ignite release.
> > Instead, we release only small client on it's own.
> > Pros:
> > - Fast and (sorry) agile release cycle!
> > - No need to wait for months for new Ignite version
> > - No need to sync features between different clients
> > Cons:
> > - More votes, more artifacts, more release-related code and scripts
> >
> > 3) *Hybrid* - all clients are hosted in a single separate repository and
> > released in sync with each other, but not with Apache Ignite. Balanced
> mix
> > of pros/cons from #1 and #2 approaches.
> > Pros:
> > - Relatively fast release cycle
> > Cons:
> > - Still need to sync features between clients
> >
> > I think that we should start moving our clients to #2 or #3 approaches to
> > get greater momentum from community, What do you think?
> >
> > Vladimir.
>
>

Re: Thin clients release cycle

[Petr Ivanov]

I would vote for single repository and the following release scheme: we build 
and release everything, but deliver only that modules, which have actual 
features / bugfixes, skipping other from release iteration until new changes 
come into them.

Also, I’d propose versioning scheme, that will reflect Apache Ignite’s 
compatibility, i.e. if thin client requires features from Apache Ignite 2.4, 
then it’s own version will be 2.4.A.B (where A - own major version, that will 
be reset every new Apache Release, B - minor/fix version for minor / quick 
fixes goals that will be reset every new A version). 



> On 6 Apr 2018, at 16:15, Vladimir Ozerov  wrote:
> 
> Igniters,
> 
> Over the last year we saw dramatic increase in demand for lightweight thin
> clients. We already have four: JDBC, ODBC, .NET, Java. In future we are
> going to have even more: NodeJS, PHP, Python, Go, whatever. I'd like to
> start a discussion on how are we going to host them. There are several
> approaches.
> 
> 1) *Monolith* - everything is hosted in a single repository and released as
> a single artifact. This is our current approach.
> 
> Pros:
> - Easy to manage
> Cons
> - Long release cycle
> - Client features must be developed in sync with each other which would be
> very hard should we have > 5-6 different clients:
> 
> 2) *Modules* - clients are moved to separate repositories with their own
> release cycles. JDBC is released separately, ODBC separately, .NET
> separately, Java (guess what?) - separately, etc..They could have different
> timelines, different feature sets, different release notes, different
> versions. This is natural approach employed by multitude of vendors.  When
> new feature is added we do not need to wait for Apache Ignite release.
> Instead, we release only small client on it's own.
> Pros:
> - Fast and (sorry) agile release cycle!
> - No need to wait for months for new Ignite version
> - No need to sync features between different clients
> Cons:
> - More votes, more artifacts, more release-related code and scripts
> 
> 3) *Hybrid* - all clients are hosted in a single separate repository and
> released in sync with each other, but not with Apache Ignite. Balanced mix
> of pros/cons from #1 and #2 approaches.
> Pros:
> - Relatively fast release cycle
> Cons:
> - Still need to sync features between clients
> 
> I think that we should start moving our clients to #2 or #3 approaches to
> get greater momentum from community, What do you think?
> 
> Vladimir.

Thin clients release cycle

[Vladimir Ozerov]

Igniters,

Over the last year we saw dramatic increase in demand for lightweight thin
clients. We already have four: JDBC, ODBC, .NET, Java. In future we are
going to have even more: NodeJS, PHP, Python, Go, whatever. I'd like to
start a discussion on how are we going to host them. There are several
approaches.

1) *Monolith* - everything is hosted in a single repository and released as
a single artifact. This is our current approach.

Pros:
- Easy to manage
Cons
- Long release cycle
- Client features must be developed in sync with each other which would be
very hard should we have > 5-6 different clients:

2) *Modules* - clients are moved to separate repositories with their own
release cycles. JDBC is released separately, ODBC separately, .NET
separately, Java (guess what?) - separately, etc..They could have different
timelines, different feature sets, different release notes, different
versions. This is natural approach employed by multitude of vendors.  When
new feature is added we do not need to wait for Apache Ignite release.
Instead, we release only small client on it's own.
Pros:
- Fast and (sorry) agile release cycle!
- No need to wait for months for new Ignite version
- No need to sync features between different clients
Cons:
- More votes, more artifacts, more release-related code and scripts

3) *Hybrid* - all clients are hosted in a single separate repository and
released in sync with each other, but not with Apache Ignite. Balanced mix
of pros/cons from #1 and #2 approaches.
Pros:
- Relatively fast release cycle
Cons:
- Still need to sync features between clients

I think that we should start moving our clients to #2 or #3 approaches to
get greater momentum from community, What do you think?

Vladimir.