Bit belated... For what's it worth, I'm fine either way.
I'd be leaning towards 5.0, since forcing synchronized client and server
upgraded for any feature is tricky for many organizations.The new major version
number would be a warning flag.
Or phrased differently, if this does not warrant 5.0, what does?
Since PHOENIX-3010 was mentioned, should we put that in the release.
Also, is there no graceful way at all to upgrade the server side first and
clients later with some graceful fallback?(I think there's a way to disable the
auto-upgrade by the first connecting new client, and instead do that with a
command. Will the new client 4.8 client understand the old 4.7 index format.If
there is any way we should be clearly documenting that.)
Thanks.
-- Lars
From: James Taylor <jamestay...@apache.org>
To: "dev@phoenix.apache.org" <dev@phoenix.apache.org>
Sent: Monday, June 20, 2016 5:23 PM
Subject: Re: [DISCUSS] name next release 5.0 or 4.8?
I agree with this as well, keeping with the 4.8 name.
On Mon, Jun 20, 2016 at 5:05 PM, Enis Söztutar <enis....@gmail.com> wrote:
> I think it is fine to name this 4.8 as long as the release notes contain
> sufficient explanation.
>
> Enis
>
> On Mon, Jun 20, 2016 at 1:19 PM, Cody Marcel <cmar...@salesforce.com>
> wrote:
>
> > Breaking backwards compatibility seems like a 5.0 type of change.
> >
> > On Mon, Jun 20, 2016 at 2:10 PM, James Taylor <jamestay...@apache.org>
> > wrote:
> >
> > > We're just about ready to roll an RC for our next release. There's been
> > > some great work to get local indexes on top of public HBase APIs which
> is
> > > awesome. However, local indexes created before this release will not be
> > > maintained correctly when the server has been upgraded to 4.8 while the
> > > client is still on 4.7 or earlier. The same goes for indexes on views,
> > for
> > > which the row key structure was changed.
> > >
> > > Once the upgrade code kicks in (when any new client connects with the
> new
> > > server), both local indexes and indexes on views are disabled. Local
> > > indexes would get rebuilt asynchronously when the MR job is started and
> > > view indexes would need to be manually rebuilt.
> > >
> > > Should we go with naming this release 4.8, since
> > > - only indexes are affected
> > > - outside of local index and view index usage, the client-side can be
> > > upgraded independently of the server side.
> > > - these are somewhat advanced features not used by the majority of
> users
> > > - we can document the behavior and users can handle upgrade as required
> > >
> > > Or should we go with naming this release 5.0, since
> > > - users won't read the documentation and will be forced to upgrade both
> > the
> > > client and server at the same time if they're using local indexes or
> view
> > > indexes.
> > > - we can implement PHOENIX-3010 to give users a path toward still
> > updating
> > > the client and server sides independently
> > >
> > > Thanks,
> > > James
> > >
> >
>
