"Political" issue about planned FreeMarker 3 activity

[Daniel Dekany <dd...@freemail.hu>]

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

Re: "Political" issue about planned FreeMarker 3 activity

[David E Jones <de...@dejc.com>]

Daniel,

This is a very real issue for projects that have been around for a long time. From my experience starting fresh, or moving to a new version that lets go of legacy issues (doesn’t try to be backward compatible) can result in a dramatic improvements. For some improvements this is necessary anyway, and as ideas for these build up over time it’s great to do them as a big set of changes.

It could attract new contributors, but is at least likely to attract new users and the attention of current users. Some current users (myself included!) may have issues with certain changes, but if the overall direction is good some pain here and there for a good reason is well worth it. If there are any deal killers you’ll get feedback on them, though maybe not until after getting a code base out there (or even a release) that people can try.

I agree with the sentiment that FM2 is stable and sturdy enough that it isn’t likely to require a lot of effort to maintain. As an open source developer there is always some balance between community feedback and what you personally want to work on. When it comes right down to it your own passion is the most important. If something is important enough to someone using the software, they can dive in and help with it (though many are more likely to complain and guilt you into doing it). 

Your point that with a simpler code base it will be easier for others to get involved is very important. New contributors won’t be familiar with legacy issues and are more likely to contribute changes that break those. It will be MUCH easier to get involved with a new cleaner code base.

I like the idea and it’s exciting to see you thinking in this direction. FreeMarker is a great tool and while I’d personally like to get more involved the current code base is intimidating.

-David


> On 8 Feb 2016, at 11:41, Daniel Dekany <dd...@freemail.hu> wrote:
> 
> 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 <wi...@apache.org> 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 <dd...@freemail.hu>
>>> 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: sergio.fernandez@redlink.co
>>> w: http://redlink.co
>>> 
> 

Re: "Political" issue about planned FreeMarker 3 activity

[Daniel Dekany <dd...@freemail.hu>]

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 <wi...@apache.org> 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 <dd...@freemail.hu>
>> 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: sergio.fernandez@redlink.co
>> w: http://redlink.co
>>

Re: "Political" issue about planned FreeMarker 3 activity

[Jacopo Cappellato <ja...@gmail.com>]

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 <wi...@apache.org> 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 <dd...@freemail.hu>
> 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: sergio.fernandez@redlink.co
> w: http://redlink.co
>

Re: "Political" issue about planned FreeMarker 3 activity

[Sergio Fernández <wi...@apache.org>]

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 <dd...@freemail.hu> 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: sergio.fernandez@redlink.co
w: http://redlink.co

Re: "Political" issue about planned FreeMarker 3 activity

[jean-frederic clere <jf...@gmail.com>]

On 02/06/2016 11:47 AM, Daniel Dekany wrote:
> What do you think? Can we (well, me initially, as I said) do this?
> 
> -- 

If we think the community will be able to support the 2 versions, we
should go for it.

Cheers

Jean-Frederic