Hi, Am 23.09.2010 15:50, schrieb Justin Edelson: > Is the problem you're referring to SLING-1797 or something larger?
This is just the issue to track the change of the default. What I have in mind is effectively the case where something now succeeds, which used to fail: modifying a checked-in node. Regards Felix > > As far as I know, the only non-backwards-compatible change is that > something[1] which would otherwise fail now succeeds. Everything else > that was done in SLING-1573 was (or at least should be) > backwards-compatible. > > To me, this type of non-backwards-compatible change is acceptable, but > can understand if I'm in the minority on that. > > Justin > > [1] modifying a versionable and checked-in node > > On 9/23/10 3:13 AM, Felix Meschberger wrote: >> Hi, >> >> I just stumbled on a problem we have internally caused by the new >> versioning support; so I would like to pick this up again. >> >> As of SLING-1573 [1] a modification operation by default tries to >> checkout and checkin if required. In fact the issue also notes that this >> is not strictly backwards compatible. >> >> IMHO we should really strive for being backwards compatible if at all >> possible, particularly in a case where "per-default-enablement" of a new >> feature can be done with simple configuration provision. >> >> Therefore I suggest we should change the default to being "no versioning >> at all" (tracked with SLING-1796 [2]). >> >> Regards >> Felix >> >> [1] https://issues.apache.org/jira/browse/SLING-1573 >> [2] https://issues.apache.org/jira/browse/SLING-1796 >> >> Am 14.06.2010 17:30, schrieb Justin Edelson: >>> I'm starting to hack on the post servlet to get it to support JCR >>> versioning. It is actually much simpler than I thought it would be. >>> Which leads me to believe I'm missing something big :) >>> >>> Would appreciate any comments/feedback: >>> http://codereview.appspot.com/1690041 >>> >>> Thanks, >>> Justin >>> > >
