I agree with this as well, keeping with the 4.8 name. On Mon, Jun 20, 2016 at 5:05 PM, Enis Söztutar <[email protected]> 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 <[email protected]> > wrote: > > > Breaking backwards compatibility seems like a 5.0 type of change. > > > > On Mon, Jun 20, 2016 at 2:10 PM, James Taylor <[email protected]> > > 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 > > > > > >
