I didn't really see the need to push out two releases which both contains incompatible changes in a short time frame. If people want the bug fixes that are currently on master, I think it would be better to create a 1.x support branch, backport those and release this branch quickly. And keep master on 2.0-SNAPSHOT for a while until we're satisfied with the state.
But if the community want to pursue the 2.0.0 release as it is, that's fine with me, I can restart a vote quickly, as I haven't deleted the staging repository or tag yet. Guillaume 2018-06-01 0:10 GMT+02:00 Jonathan Valliere <[email protected]>: > Push out the release as proposed in the cancelled vote. Then proceede to > work on refactoring in a new branch. When the refactoring is completed, > push another official release. This way the versions in maven will be > clearly known as before and after the refactor when debugging issues. > > On Thu, May 31, 2018 at 5:33 PM Guillaume Nodet <[email protected]> wrote: > > > You mean commit in a branch ? Not sure to understand what you mean ? > > > > 2018-05-31 23:29 GMT+02:00 Jonathan Valliere <[email protected]>: > > > > > From a codebase stability perspective, maybe you should commit a > version > > > number with the bug fixes. Then do the refactoring in its own version > > > number as to not confuse the two when trying to figure out if the > > > refactoring broke something or if the previous bug fixes broke > something? > > > > > > On Thu, May 31, 2018 at 1:59 PM, Lyor Goldstein <[email protected] > > > > > wrote: > > > > > > > >>> > I disagree with the characterization that they do not have a > > "real > > > > concept > > > > > behind them" they represent contracts of entities that have similar > > > > > attributes. IMO, all the various *XxxHolder*(s) represent an entity > > > that > > > > > provides whatever these "attribute" interfaces hold. > > > > > > > > >>> Well, I would agree on this principle in theory. > > > > However, I've seen no evidence throughout the code that this is > > actually > > > > useful. > > > > > > > > Here is something that I see as a useful consequence of these > "marker" > > > > interfaces - some degree of standardization: e.g., if more than 1 > > entity > > > > displays the same "behavior" and/or "attributes", it makes sense to > > call > > > > them by some standard name - e.g., avoid *getSession, > getClientSession, > > > > getCurrentSession, getEstablishedSession* in different entities that > > > > basically expose a *ClientSession*. To me it is another aspect of the > > > > D.R.Y. principle since it makes it easier to search for code that > > refers > > > to > > > > a known entity knowing that it will use a standard way to expose it. > > > > > > > > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > > -- ------------------------ Guillaume Nodet
