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