groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <Jason.Winneb...@windstream.com>
Subject RE: Maven coordinates going forward
Date Mon, 27 Mar 2017 18:08:00 GMT
The key thing in my mind is that you can't make a change that breaks 100% of libraries at one
time without fracturing the community or at least introducing a major hindrance to upgrade
that will mean maintaining 2.x series for a very long time. Even if the upgrade process is
as easy as a recompile, there are a lot of published libraries no longer maintained. Even
for the ones that are maintained, there are people who might not want to be forced to upgrade
every library. I'm not a Grails user, but my impression is that the framework relies on a
lot of plugins and is one of the (if not the most) active Groovy communities and I have a
hard time envisioning how that upgrade path will take. You'd have to maintain Groovy 2 and
Groovy 3 versions of each plugin, and to upgrade you'd have to upgrade everything at one time
to the (most likely) latest version.

What is the possibility that the package names are changed, the parser, metaprogramming model,
etc. that all break in Groovy 3 change, but yet still have a compatibility JAR implementing
the minimal Groovy 2.x classes in a way that allows interoperability with Groovy 3 code? Theoretically
at a worst case, Groovy 3 should be able to view Groovy 2 classes the same way as any other
Java class. I think many concerns would be lifted if Groovy 2 and 3 could co-exist at the
same time, allowing you to upgrade incrementally.

Jason

-----Original Message-----
From: Russel Winder [mailto:russel@winder.org.uk] 
Sent: Monday, March 27, 2017 1:29 PM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward

On Mon, 2017-03-27 at 12:47 -0400, Gerald Wiltse wrote:
> 
[…]
> Specifically, reaching out to the Python maintainers for guidance.  In 
> hindsight, someone deeply involved usually has a very clear vision of 
> "What we should have done instead was...".  It would be a major missed 
> opportunity if nobody pursues that avenue.
> 
[…]

I cannot speak for the core developers, but I am sure I could ask them via the various Python
mailing lists. The introduction of Python 3 was not handled well in my view from the social
and management perspective and this led to a majority of the tribalism issues that were seen.
The changes to the data model were large, and needed, and affected library writers more than
end users. The biggest change that affected end users was the shift from ASCII to Unicode
as the representation of strings.
This broke any code using strings for networking.

Not having packages such as future and six, and tools such as 2to3 properly in place before
the mass push to Python 3 was a bit of a problem.

However the single biggest problem was that many influential people said "Python 3, no way"
from the outset. Also a couple of high profile projects said "the issue of strings is too
big, we will not change". A well-thought of Python distribution refused to accept the existence
of Python 3, and out of that that distribution is now dead and Anaconda/Miniconda from Continuum
Analytics is now the default distribution for people not use an OS with packaging – or actually
sometimes anyway. Also a few Linux distributions based on mass use of Python are based on
code that is at least a decade old (Scientific Linux, I am looking at you).

All of this led to a Python 2 vs Python 3 warfare that was almost totally nothing to do with
technicalities. It was to do with vested interests and financial muscle. It became tribal
almost like the Green/Purple Drazi in "Geometry of Shadows" an episode of Babylon 5 htt ps://www.youtube.com/watch?v=AcBTOU7RvbU
.

It has taken a long time for Python 3 to become ascendant but ascendant it is. The old "stick
with Python 2" project have quietly enabled Python 3 and tried to avoid any publicity about
this.

So the change was a technical success and a management and social failure.

Thus changing the package names is a management problem not a technical problem. So the only
real question is how to enable redirection at dynamic link time.
 
--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

This email message and any attachments are for the sole use of the intended recipient(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all copies of the
original message and any attachments.
Mime
View raw message