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
> >
>

Reply via email to