Is the problem you're referring to SLING-1797 or something larger? 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 >>
