groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russel Winder <>
Subject Re: Maven coordinates going forward
Date Thu, 30 Mar 2017 07:54:00 GMT
On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
> We have to keep in mind that there's a larger story here, which is
> supporting Groovy as a module. And this *will* require package
> changes and
> binary breaking changes. So I don't think the status quo is
> acceptable in
> the long run.

So why not make Groovy 3 the place to do this?

Whatever has been said about the Python situation, the core problem was
not the breaking change, the problem was the lack of active management
of the change.

Python is a source deployment language where JRE-based langauges are
not. Thus JRE-based application have the classic COBOL, FORTRAN, and
Fortran problem of "we've lost the source" (banks and governments are
the usual suspects for this). I would exclude this situation from our
thinking. Organisations in such a state (as some UK banks and the UK
government is) should take it as an opportunity to revolutionise (which
the UK government is, cf. the job adverts for COBOL, FORTRAN and
Fortran knowledgeable people who also know Python, Java, etc.

Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in
the mix made for a very hard time. Allowing only 2.7 and 3.4+ in the
mix made for a much, much easier time. So initially moving from Python
2 to Python 3 was a manual task (bad management by the Python 3 folk),
then came the six generation of upgrade tooling (a start). By dropping
2.6 and 3.3, we get the far nicer future upgrade tooling (which works
nicely to create 2.7 and 3.4+ compatible code). The moral here is
choose the versions being upgraded from and to, and then make some nice

So if we assume a base of Groovy 2.4 and ignore all previous Groovys
and the breaking change of 3.0 can we write some Groovy (obviously :-)
scripts that automate source changes?

If the Python 2 → Python 3 breaking change had been more actively
managed with earlier arrival of six and future, the problems would have
been much less. Most of the vocal Python 2 Remainers have now made
their codes run on both Python 2 and Python 3, and there are very few
complaints about providing Python 3 only. OK so there are still a few
people who say "we must support Python 2.5" but those people are few
and far between and are, in the main, totally ignored. Python 4 will
undoubtedly have breaking changes, but they will be better managed in
terms of supporting multi-version working and automated (well at least
semi-automated) upgrading and mixed-version working. The lessons of six
and future have been well learned.

So Groovy will have breaking changes, this is right and proper. Put in
place tools for upgrading, and support multi-version working where
possible and practical. Do not be swayed by calls for "we must change
nothing, backward compatibility". They have a version of Groovy that
works for them so they should not upgrade – ever again. That must not
stop the rest of us from progressing.

Dr Russel Winder      t: +44 20 7585 2200   voip:
41 Buckmaster Road    m: +44 7770 465 077   xmpp:
London SW11 1EN, UK   w:  skype: russel_winder
View raw message