Monday, June 12, 2017, 6:35:57 PM, David E Jones wrote:
>
> That's fantastic Daniel, it's great to see the whole summary in one place.
>
>
>
> One thought is that it might be helpful to split the items under 'API and
> architecture' and 'Template language' into those intended for a first release
> and those that are 'nice to haves' that may come later. My impression is that
> there are a lot of great ideas in there but the first pass on FM3 could be
> much easier by limiting the scope.
>
>
>
> What should be in the first release versus later is a matter of opinion, and I
> have my own biases based on how I typically use FreeMarker. From a read
> through it looks like a few things in the 'Template language' section could
> wait until after the first release, and a couple in the 'API and architecture'
> section (like Android compatibility, but I don't know much about what would be
> involved there aside from supporting at least back to Java 7).
>
>
>
> The most important ones to get before the first in are probably the breaking
> changes and clean ups (including removal of deprecated features). Other things
> like named bodies or fragments in macros would be nice, but seem like they
> could be added later while remaining backward compatible with FM3 release 1
> (v3.0.0 or whatever).
>
>
>
> As a first pass these changes (breaking changes and cleanups) would also push
> toward the goal of making it easier for others to get involved and contribute
> more. It might even be a good idea to mention that in this wiki document,
> basically plant a seed that might result in more contributors.
Yeah, I know it's a lot. The problem is that certainly all of those
bullet points will cause some non-backward-compatible changes, and
thus can't be done (or at least risky to do) after 3.0.0 is released.
That's why they are there actually (because I have a lot more
ideas...). We can of course do some preview releases any time,
especially as things get more and more final, but they won't be
backward compatible. For libraries (as opposed to stuff that's
primarily accessed by humans through UI) backward compatibility seems
to be a key problem when developing stuff that's used outside your
controlled (company) environment... you need to design with great
foresight to avoid that, but I believe that that too easily fails in
reality without actually experiencing things as you implement and test
them.
As of Android support, we are on Java 7 exactly because of that, but
you have further restrictions. Like javax.bean is not available. Nor
using SLF4J is normal. This will possibly mean that we need to
modularize further, or make logging pluggable in the core after all.
So I'm just not yet sure that we can safely postpone that. Maybe we
can. We will see when it gets there, or when someone invests into this
question (someone?).
> -David
>
>
>
> ![](https://link.nylas.com/open/3gy06hjaelmtsemvo28wr1tmc/local-
> 2cc91277-d0f4?r=ZGV2QGZyZWVtYXJrZXIuaW5jdWJhdG9yLmFwYWNoZS5vcmc=)
>
>
> On Jun 12 2017, at 4:34 am, Daniel Dekany wrote:
>
>> I have made a page about what FreeMarker 3 is about and how it should
> look, because all this was only extractable from mailing list
> discussions so far.
>
>>
>
>> https://cwiki.apache.org/confluence/display/FREEMARKER/FreeMarker+3
>
>>
>
>> Something you are missing from it, or disagree with it? Eventually we
> should tweet this, but first of course I need some feedback.
>
>>
>
>> \--
> Thanks,
> Daniel Dekany
>
--
Thanks,
Daniel Dekany