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 <d...@haywood-associates.co.uk> > 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
