Breaking change implies 5.0 to adequately communicate the compatibility issues, IMHO
> On Jun 20, 2016, at 1: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
