phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Poon <>
Subject Re: [DISCUSS] phoenix-connectors and phoenix-queryserver release process
Date Tue, 08 Jan 2019 21:59:28 GMT
Right now the "presto connector" I'm working on also builds an uber jar
that is like phoenix-client but with some additional excludes and
relocations.  So I would need to build one for each Phoenix release.  So I
was thinking of something like:

I would think it would be the same for e.g. PQS, if we ultimately want to
build a tarball that includes everything you need to run PQS, which is the
easiest thing for users.  You need a specific Phoenix client version to
include in the bundle.

Yet at the same time, we want to avoid having many branches like Phoenix.

So maybe we can just have a single master branch, and have a 'target'
Phoenix version as a variable, with a default of the latest Phoenix release.
Then at release time we can deploy with different Phoenix version targets
as needed.

On Tue, Jan 8, 2019 at 12:50 PM Josh Elser <> wrote:

> +1 for queryserver starting out at 1.0.0, for sure. We've really made
> only a few changes for PQS over the years (the majority of code is in
> Avatica). Doesn't make sense to follow the 'normal' Phoenix versioning.
> Assuming the connectors is similarly slow moving, I'm in favor of the
> same for that too.
> I asked on the PR for the queryserver repo: how are people going to
> interact with these? Something as simple as:
> * How will PQS know where the phoenix-client.jar is?
> * Where do users invoke from?
> On 1/8/19 2:34 PM, Thomas D'Silva wrote:
> > We are currently working on moving the connectors and queryserver to
> their
> > own repos (see and
> >
> > IMO we should have a single branch for each repo that depends on a
> released
> > version of Phoenix/HBase. I thinnk we should start the pom versions at
> > 1.0.0. We can then have connectors or queryserver releases independent of
> > Phoenix. For the connectors, I think we should release all of them when
> we
> > have a connector release. Same with queryserver (release both the server
> > and client).
> > What do folks think?
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message