Hi Daniel, thanks for sharing your ideas with the community. I think I have three different angles to reply you:
1) As a developer, I usually like the approaches of fresh starts, where you can apply what you have learnt so far to design the best possible solution without the need of keep legacy support. You may fail, and never get FM3 released, which is fair enough; but the project will benefit from the lessons learnt. 2) As a mentor, I fear that maintaining two parallel branches will be hard with such small team. But I think that FM2 is stable enough to just require minor bugfixes, focusing all project's effort in FM3. Then should be fine. 3) From the ASF point of view there is no issue at all. A project (or podling) is completely autonomous to take the technical decision they consider the best for the project. Saying that "one of the reasons FM was accepted into the incubator is that existing Apache projects (and Apache members) are relying on FM2" shouldn't be an impediment for the project to evolve. Some project will keep using FM2, some other will move on to FM3; as simple as that. Hope that helps. Cheers, On Sat, Feb 6, 2016 at 11:47 AM, Daniel Dekany <[email protected]> wrote: > My goal with what I call "FreeMarker 3" is to mercilessly get things > right, while re-using source code as much as possible. I don't want to > change the "flavor" of FreeMarker, I mean, it should come with roughly > the same features (even if modularized out), same core > beliefs/paradigms (${noSuchVar} should be an error, etc.), and > *similar* but not identical look-and-feel (though later I think a > Velocity/WebMacro-like option would be desirable too). I would like to > give up some dynamism for the sake of better toolability though. I > also pant to give more focus to non-Web applications, such as source > code generation, where white-space control is important. > > The political issue comes from that, I care about giving the best > FM-ish template engine I can, and I don't want tradition to be in may > way (that's what FM2 is for). After 12+ FM2 technical support and > maintenance and accumulated wisdom that's what motivates me. (Yes, > that's just me, but we know that the only hope for FM3 is that I > bootstrap it with a lot of work, and only then there's a slight hope > that others will join to that much more attractive branch.) And so, > what if, me in agreement with others here think that, just as an > example, `s?capFirst` and `s!default` are too weird, and `s|capFirst` > and `s?:default` is a better compromise. Trivial change technically, > not a paradigm shift at all, but for the outsider, it feels like a > sharp change. Or, we decide that, if we forget the past for moment, > FTLValue and FTLNumber are a better names than TemplateModel and > TemplateNumberModel. Trivial change again, but very visible for the > outsider. Or, a deeper change, we decide that #include sucks after all > (hint: it does). And so on. These changes will pile up. Nobody would > say a bad word about these if it's just yet another new template > language (to die due to lack of attention), but if we "market" this as > FreeMarker 3... is that OK to do? And is that OK for the ASF, because, > one of the reasons FM was accepted into the incubator is that existing > Apache projects (and Apache members) are relying on FM2. Well, they > don't rely on FM3, and it's not yet proven that they will if there > ever will be an FM3. > > What do you think? Can we (well, me initially, as I said) do this? > > -- > Thanks, > Daniel Dekany > > -- Sergio Fernández Partner Technology Manager Redlink GmbH m: +43 6602747925 e: [email protected] w: http://redlink.co
