All JSPWikil changes (also markup changes) are documented in the ChangeLog. Larger changes possibly breaking compatible with older versions are typically linked to specific releases. Which allows 3rd party developers to keep customisations compatible to certain version baselines.
JSPWIKI.Properties, on the other hand, have a different purpose. They provide tools for the administrator to manage the setting of certain features. Properties are not meant to replace the version control mechanism. In this particular case (support for the triple %) ; there is no risk to break any customisations. Basically the proposal exploits a current rendering bug, and turns it into a useful feature, which would offer more flexibility to JSPWiki for future front-end customisations. The JSPWiki syntax, although quite stable, has surely evolved over time. (many small incremental steps) We did not introduce on/off syntax properties for this, and that has worked very well. EG Many new %%classes were added gradually. And with Haddock becoming the default template, even more %%bootstrap-classes are now available as part of the default JSPWiki deployment. (potentially breaking some customisations) Note As the editor preview function relies on a SERVER side rendering of a page, all customisations, plugins, filters which are installed are automatically applied as well. So also covering syntax related customisations. Br, dirk On Sun, Apr 21, 2019 at 11:59 PM Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> wrote: > Hi Murray, > > apologies for the late response, catching up with e-mail after some > holidays :-) > > breaking syntax changes should be optional, most probably disabled by > default, I think we all agree to that. But I don't see > why non breaking changes should be, if they aren't breaking anything. Said > that, I'd discuss each one of them on a case > by case basis, mostly to see if they make sense, they really don't break > existing markup, etc. and applying lazy consensus > (= no need of formally voting them) to bring those changes in. > > In this particular case, the proposed syntax changes garbage markup text > into consistent markup text, so it seems to me > that it would be very improbable to came across that specific syntax on > pre-existing installations. And seems even more > improbable that custom plugins or filters have been developed to change / > edit this garbage markup into something else. > > The wiki syntax hasn't been switchable until recently (when the markdown > module came in), and even now, IIRC, the frontend > is coupled to the main syntax, so previews and edits don't go the way they > are expected when using alternatives to the main > syntax. Thus, syntax customizations via filters or plugins would still > work, but they would be cumbersome enough to use, the > effort to carry them on would not be worthwile, IMO. > > Of course, it is possible that such installations may exist, but they seem > to me so highly unlikely that I see this proposed > syntax enhancement as not breaking. > > Lastly, this is only my opinion, by no means authorizative, so I'd like to > hear what do others think about this. > > > cheers, > juan pablo > > > > On Sat, Apr 13, 2019 at 12:39 AM Murray Altheim <murra...@altheim.com> > wrote: > > > Hi Juan Pablo, > > > > I'm sorry to say but no, (I'm smiling while I write this), your last > > message > > didn't clear up (for me) your intention. > > > > You seem to indicate that you believe this particular proposal wouldn't > > break > > existing installations, but that cannot be known. So while I appreciate > > your > > approach to the question, you seem to be agreeing with me in saying that > > "if > > the proposed markup breaks existing installations, I'd be a big no-no of > > bringing it in". > > > > So maybe I was the one not being very clear. I'll try again: > > > > Because JSPWiki has been around for around 20 years*, we can't know the > > extent of user customisations/modifications and plugins that people are > > actually using, as there's no requirement that users publish or publicise > > their customisations. JSPWiki has from the beginning been promoted as a > > "programmer's wiki" so it's likely been customised for various purposes. > > I've certainly made many, many customisations (though always via plugins > > that didn't modify the main syntax, though that's anyone's option). > > > > I'm deliberately taking a very conservative approach here, to represent > the > > interests of these unknown users. And in doing that I'm proposing a > policy > > for the group: that *any* syntax changes on a 20 year old project should > > be permitted (and perhaps default enabled), but be optional. Since this > > isn't difficult to implement I don't think it unreasonable. This would be > > to require that, even if the default for the new syntax is enabled, > there'd > > still be an option to disable it in jspwiki-custom.properties. > > > > In this way we can continue to make changes to syntax (and continue to > > improve JSPWiki without being held back by existing implementations) but > > still permit existing users to disable those features if they find them > > incompatible with their existing, customised installations. > > > > Is that any clearer? > > > > Cheers, > > > > Murray > > > > * version 1 of the About page on ecyrd.com was from 2001 but I think the > > project is older, maybe circa 1999, we'd have to ask Janne. There's a > > review of it in 2001 on http://wiki.c2.com/?JspWiki > > > > > Hi Murray, > > > > > > having to edit wiki-pages in order to comply with the new markup is > > indeed > > > a strong hint to not push newly proposed > > > markup, or at least make it optional. On this particular case however, > > old > > > versions of the markup would render > > > "incorrect" text, that is, the expected and the actual output diverge > > > enough that most probably the proposed syntax > > > isn't currently used; hence, in this particular case, I'm more inclined > > to > > > not make it optional. > > > > > > Re-reading my first e-mail, it seems that I don't prefer optional > markup > > > at > > > all, but that was poorly expressed, I was > > > thinking only on the new proposed markup, not as a general rule. > > > > > > Of course, if the proposed markup breaks existing installations, I'd > be a > > > big no-no of bringing it in, or at least, as > > > you say, make it optional (and defaulted to not activating it). > Anything > > > subject to break existing markup should be > > > optional and deactivated by default (IMO), or even published as another > > > MarkupParser, but again, in this particular > > > case I'm not thinking that existing markup would need to be rewritten. > > > Hope > > > I make more sense now.. > > > > > > > > > cheers, > > > juan pablo > > > > > > > > > On Fri, Apr 12, 2019 at 12:11 AM Murray Altheim <murra...@altheim.com> > > > wrote: > > > > > >> Hi Juan Pablo, > > >> > > >> I think this really comes down to a policy decision, insofar as in the > > >> history > > >> of this project we've come upon similar decisions, but to my memory I > > >> can't > > >> think of how we've resolved them. > > >> > > >> So yes, we can always recommend implementers/installers read the > change > > >> logs > > >> and documentation, but if someone has a existing installation of wiki > > >> pages > > >> that this proposal would be in conflict with, that would put that site > > >> into > > >> a situation where they'd likely not be able to ever upgrade to the > next > > >> version of JSPWiki unless they could somehow edit all those pages, > which > > >> in > > >> practicality means (probably) never. The alternative would be to be > able > > >> to > > >> disable this new feature. > > >> > > >> So I'm happy to amend my original proposal, which is to have this as > an > > >> option, but the default is enabled. That way, anyone in the situation > > >> where > > >> a syntax change would create conflicts they could at least upgrade to > > >> the > > >> latest version of JSPWiki and simply disable the feature. > > >> > > >> Would that be too onerous? (Frankly, obviously, I have no idea if > there > > >> are > > >> any users out there where this would be a conflict, but I'm > suggesting a > > >> policy decision where any new syntax features/changes would have an > > >> enable/ > > >> disable flag rather than simply be included). > > >> > > >> Cheers, > > >> > > >> Murray > > >> > > >> > Hi, > > >> > > > >> > I'd prefer not to have optional markup, as it would lead to more > > >> complex > > >> > setups / things to have in mind when > > >> > setting up JSPWiki. Also we're in the middle of transitioning to > 2.11 > > >> so > > >> > breaking changes should be expected, > > >> > as long as their clearly depicted on the NewIn.. page. > > >> > > > >> > Also, in this particular case the alternative feels cumbersome, so > it > > >> > looks > > >> > to me as a welcome addition, and > > >> > is likely to break not too much wikipages (%%% not being a typical > > >> text > > >> > for > > >> > a wiki page). Again, in this case, > > >> > people upgrading should check the NewIn.. page for all kinds of > > >> changes. > > >> > In > > >> > any case, that's my opinion only, > > >> > what do you people think? > > >> > > > >> > best regards, > > >> > juan pablo > > >> > > >> > > > ........................................................................... > > >> Murray Altheim <murray18 at altheim dot com> = = > > >> === > > >> http://www.altheim.com/murray/ > === > > >> === > > >> = = > > >> === > > >> In the evening > > >> The rice leaves in the garden > > >> Rustle in the autumn wind > > >> That blows through my reed hut. > > >> -- Minamoto no Tsunenobu > > >> > > >> > > >> > > >> > > > > > > > > > > > > ........................................................................... > > Murray Altheim <murray18 at altheim dot com> = = > === > > http://www.altheim.com/murray/ === > > === > > = = > === > > In the evening > > The rice leaves in the garden > > Rustle in the autumn wind > > That blows through my reed hut. > > -- Minamoto no Tsunenobu > > > > > > > > >
