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
>

Reply via email to