Discussion:
[Freemarker-devel] Switching to Java 5 in the 2.3.x branch too?
Daniel Dekany
2015-07-04 19:34:24 UTC
Permalink
Any opinions, especially against it?

To keep back porting to the 2.3.x branch (or, currently, forward
porting to the 2.4.x branch) less expensive, and to ease development
in general, I think it doesn't worth keeping support for older Java
version anymore in the 2.3.x branch. (2.4.x was always Java 5.)
There's the backward compatibility promise in 2.3.x, but I think that
doesn't have to apply to the runtime environment requirements that
strictly.

Besides, I have already pulled a such change by requiring Java 1.4
instead of 1.2 starting with 2.3.21 (2014-10-12), but that was a less
steep change.
--
Best regards,
Daniel Dekany
Denis Bredelet
2015-07-05 09:39:52 UTC
Permalink
Hi Daniel,
Post by Daniel Dekany
Any opinions, especially against it?
To keep back porting to the 2.3.x branch (or, currently, forward
porting to the 2.4.x branch) less expensive, and to ease development
in general, I think it doesn't worth keeping support for older Java
version anymore in the 2.3.x branch. (2.4.x was always Java 5.)
Isn’t it time to make 2.4.x the main branch instead?
Post by Daniel Dekany
There's the backward compatibility promise in 2.3.x, but I think that
doesn't have to apply to the runtime environment requirements that
strictly.
In the real world the runtime environment is a big part of the backward compatibility equation.

The question is, is anyone still on Java 1.4 and using Freemarker? How likely is that?
Post by Daniel Dekany
Besides, I have already pulled a such change by requiring Java 1.4
instead of 1.2 starting with 2.3.21 (2014-10-12), but that was a less
steep change.
Did you have anyone stuck at 2.3.19/20 then because of the runtime change?

— Denis.
Post by Daniel Dekany
--
Best regards,
Daniel Dekany
Daniel Dekany
2015-07-05 13:04:43 UTC
Permalink
Post by Denis Bredelet
Hi Daniel,
Post by Daniel Dekany
Any opinions, especially against it?
(I have forgotten to state clearly... 2.3.23 will be Java 1.4. It's
about 2.3.24.)
Post by Denis Bredelet
Post by Daniel Dekany
To keep back porting to the 2.3.x branch (or, currently, forward
porting to the 2.4.x branch) less expensive, and to ease development
in general, I think it doesn't worth keeping support for older Java
version anymore in the 2.3.x branch. (2.4.x was always Java 5.)
Isn’t it time to make 2.4.x the main branch instead?
Well... then, the long version follows.

2.4 contains some breaking changes, that's why it's called 2.4 (FM
version policy, which differs from the semver varation become popular
lately). If the plan goes as intended, most applications (something
like 99% of them) won't be effected, but it can still mean that 2.4.x
won't be packed in frameworks with huge user base (like Struts,
Spring, Liferay, etc.), because they will afraid of breaking the apps
of some of their users. But while it's a concern if you break even the
tinniest thing in the FreeMarker API (=> 2.4), they won't care if you
require Java 5, because they require that too anyway (or rather Java
6).

As of which is the main branch... because of what was said above, if
you add a new feature to 2.4 only, your work won't reach a big
percentage of your users. So, you add them to both branches, but as
2.4-only developments go ahead, that will become more and more
expensive to do because of merging conflicts and such. That's why I
try to squeeze as many features into to 2.3 as possible, before
switching focus to 2.4.

OTOH not switching to 1.5 also makes the development more expensive,
and most importantly, you can use generics and enums in public API-s,
and those old-style API can't be fixed later, when you switch to 1.5.
And because 2.4 is Java 5, it can also make merging harder as 2.4
crawls ahead.

And then comes a new factor, Apache incubation. It's not very inviting
for contributors to have 3 branches that you have to keep in sync for
each contribution you do. (Nor do they like pre-5 Java BTW.) So
there's an increasing pressure to switch the focus to 2.4, so 2.3.24
will be certainly the last 2.3.x that's not just maintenance and some
backportings.
Post by Denis Bredelet
Post by Daniel Dekany
There's the backward compatibility promise in 2.3.x, but I think that
doesn't have to apply to the runtime environment requirements that
strictly.
In the real world the runtime environment is a big part of the backward compatibility equation.
The question is, is anyone still on Java 1.4 and using Freemarker? How likely is that?
Or, I would reformulate that question as: is anyone still on Java 1.4
who also cares to upgrade FreeMarker? Installations that didn't get a
Java upgrade for so long probably won't play around with FreeMarker
upgrades either. (They can't upgrade any of their libs for a long
time.)
Post by Denis Bredelet
Post by Daniel Dekany
Besides, I have already pulled a such change by requiring Java 1.4
instead of 1.2 starting with 2.3.21 (2014-10-12), but that was a less
steep change.
Did you have anyone stuck at 2.3.19/20 then because of the runtime change?
I don't know about such cases. Anyone?
Post by Denis Bredelet
— Denis.
Post by Daniel Dekany
--
Best regards,
Daniel Dekany
--
Thanks,
Daniel Dekany
Denis Bredelet
2015-07-05 17:21:15 UTC
Permalink
Post by Daniel Dekany
Post by Denis Bredelet
Hi Daniel,
Post by Daniel Dekany
Any opinions, especially against it?
(I have forgotten to state clearly... 2.3.23 will be Java 1.4. It's
about 2.3.24.)
All right, sounds like you have a plan. Version 2.3.24 will be the last in the 2.3.x branch and it will receive any backporting that will be made from this point onwards.

It does make sense to make backporting to the legacy branch easier by bumping up the minimum runtime version.

If someone really needs to run 2.3.24 on Java 1.4, it will be a project in itself which « someone » will have to put resources into.

Again, I say go ahead with it if the focus is going to shift to 2.4.x from the release of 2.3.24.

— Denis.
Post by Daniel Dekany
Post by Denis Bredelet
Post by Daniel Dekany
To keep back porting to the 2.3.x branch (or, currently, forward
porting to the 2.4.x branch) less expensive, and to ease development
in general, I think it doesn't worth keeping support for older Java
version anymore in the 2.3.x branch. (2.4.x was always Java 5.)
Isn’t it time to make 2.4.x the main branch instead?
Well... then, the long version follows.
2.4 contains some breaking changes, that's why it's called 2.4 (FM
version policy, which differs from the semver varation become popular
lately). If the plan goes as intended, most applications (something
like 99% of them) won't be effected, but it can still mean that 2.4.x
won't be packed in frameworks with huge user base (like Struts,
Spring, Liferay, etc.), because they will afraid of breaking the apps
of some of their users. But while it's a concern if you break even the
tinniest thing in the FreeMarker API (=> 2.4), they won't care if you
require Java 5, because they require that too anyway (or rather Java
6).
As of which is the main branch... because of what was said above, if
you add a new feature to 2.4 only, your work won't reach a big
percentage of your users. So, you add them to both branches, but as
2.4-only developments go ahead, that will become more and more
expensive to do because of merging conflicts and such. That's why I
try to squeeze as many features into to 2.3 as possible, before
switching focus to 2.4.
OTOH not switching to 1.5 also makes the development more expensive,
and most importantly, you can use generics and enums in public API-s,
and those old-style API can't be fixed later, when you switch to 1.5.
And because 2.4 is Java 5, it can also make merging harder as 2.4
crawls ahead.
And then comes a new factor, Apache incubation. It's not very inviting
for contributors to have 3 branches that you have to keep in sync for
each contribution you do. (Nor do they like pre-5 Java BTW.) So
there's an increasing pressure to switch the focus to 2.4, so 2.3.24
will be certainly the last 2.3.x that's not just maintenance and some
backportings.
Post by Denis Bredelet
Post by Daniel Dekany
There's the backward compatibility promise in 2.3.x, but I think that
doesn't have to apply to the runtime environment requirements that
strictly.
In the real world the runtime environment is a big part of the backward compatibility equation.
The question is, is anyone still on Java 1.4 and using Freemarker? How likely is that?
Or, I would reformulate that question as: is anyone still on Java 1.4
who also cares to upgrade FreeMarker? Installations that didn't get a
Java upgrade for so long probably won't play around with FreeMarker
upgrades either. (They can't upgrade any of their libs for a long
time.)
Post by Denis Bredelet
Post by Daniel Dekany
Besides, I have already pulled a such change by requiring Java 1.4
instead of 1.2 starting with 2.3.21 (2014-10-12), but that was a less
steep change.
Did you have anyone stuck at 2.3.19/20 then because of the runtime change?
I don't know about such cases. Anyone?
Post by Denis Bredelet
— Denis.
Post by Daniel Dekany
--
Best regards,
Daniel Dekany
--
Thanks,
Daniel Dekany
Loading...