Switching to Java 5 in the 2.3.x branch too?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Switching to Java 5 in the 2.3.x branch too?

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.)
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


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switching to Java 5 in the 2.3.x branch too?

Denis Bredelet
Hi Daniel,

> 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?

> 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?

> 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.

> --
> Best regards,
> Daniel Dekany


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switching to Java 5 in the 2.3.x branch too?

Daniel Dekany
Sunday, July 5, 2015, 11:39:52 AM, Denis Bredelet wrote:

> Hi Daniel,
>
>> 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.)

>> 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.

>> 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.)

>> 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?

> — Denis.
>
>> --
>> Best regards,
>> Daniel Dekany

--
Thanks,
 Daniel Dekany


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switching to Java 5 in the 2.3.x branch too?

Denis Bredelet
> Sunday, July 5, 2015, 11:39:52 AM, Denis Bredelet wrote:
>
>> Hi Daniel,
>>
>>> 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.

>>> 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.
>
>>> 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.)
>
>>> 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?
>
>> — Denis.
>>
>>> --
>>> Best regards,
>>> Daniel Dekany
>
> --
> Thanks,
> Daniel Dekany
>


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Loading...