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 > > > >
