Thanks for the answers guys! Regarding being able to maintain two branches... One of my main concerns about FM2 is exactly that adding *substantial* new features to it starts to be rather expensive because of all the tricks required to keep backward compatibility (such as adding options to turn on/off features - also confusing for the users) and to work around some unfortunate architectural decisions of the past. Even if you still add that new feature, the maintenance of a such more complex code base will be more and more expensive. So, the way I see it, maintaining FM2 and developing the deeper new things in FM3 requires less resources than fighting all the battles inside FM2, though only after a huge initial investment. Also, we must catch more contributors, and so bring in new resources. That's easier with a code base where you can be more productive, and fight less with legacy.
-- Thanks, Daniel Dekany Monday, February 8, 2016, 11:00:57 AM, Jacopo Cappellato wrote: > I completely agree with what Sergio wrote: as a project/community, > Freemarker can take any technical decision they consider the best for the > project, including (but not limited to) deprecating an API or dropping > support for a release branch. > Of course, every project/community will have to find the right balance and > take the best decision to minimize the pain to users and developers. > > Jacopo > > On Mon, Feb 8, 2016 at 9:44 AM, Sergio Fernández <[email protected]> wrote: > >> 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 >>
