Thanks, Oscar. Yes, I forgot that, but you are right, we did say at the mini-conf back in Jun that this would be in scope for 2.0.0. It probably should be configurable so it can be disabled if nec, but by default be enabled.
Is there a ticket for it, do you happen to know? Thx Dan On Fri, 5 Jan 2018 at 12:44 Óscar Bou <[email protected]> wrote: > > Hi Dan, > > I would also considered the “always wrapped” theme, as a way to ensure > Domain Entities always are conformant to their hide/disable/validate > constraints (and other forced through actions). > > To me that was a very compelling feature at the very beginning (despite of > the current cost of invoking always wrapped). > Sure it has avoided many, many bugs in production and have ease testing a > lot. > > > I would propose this the default behaviour, but perhaps others think > different. > Probably it might be disabled (i.e., optional). > > Regards, > > Oscar > > > > El 5 ene 2018, a las 13:38, Dan Haywood <[email protected]> > escribió: > > > > Folks, > > > > as you saw, I cut a 1.16.0-RC1 release yesterday. If this passes the > vote, > > I propose this to be the last release in the 1.x codeline. > > > > For 2.0.0 we have several themes: > > - move to JDK8 > > - upgrade to DN 5.1 > > - compatibility with JEE 7 > > - meta-annotations > > - remove deprecations > > > > Quite a bit of work has been done in these areas already, but to reduce > the > > risk I propose that we have a number of milestone releases. The Apache > > Wicket project does this for the major releases, as do others I'm sure, > and > > I think it's a good practice to follow. > > > > For 2.0.0-M1, I propose: > > - move to JDK8 > > - remove deprecations > > - meta-annotations > > > > For 2.0.0-M2, I propose > > - upgrade to DN 5.1 > > - compatibility with JEE 7 > > > > You'll see that I've created releases in Isis for this (see our kanban > > board [1]). In git there's also two branches: > > - dev/2.0.0-M1 > > - dev/2.0.0-M2 > > > > When 1.16.0 is released, I'll merge into dev/2.0.0-M1. > > > > I suggest that new tickets are done as feature branches of either of > > these. This will then make it easy to (later on) rebase all of > > dev/2.0.0-M2 onto dev/2.0.0-M1 (and similarly for any -M3, -M4 branches > we > > might decide to have). > > > > Let me know if you have any thoughts/refinements/concerns relating to the > > above > > > > Thx > > Dan > > > > > > [1] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=87 > >
