apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Weise <...@apache.org>
Subject Re: [DISCUSS] changing project name to apex-library
Date Mon, 28 Aug 2017 14:57:45 GMT
On Mon, Aug 28, 2017 at 12:41 AM, Pramod Immaneni <pramod@datatorrent.com>

> > > It could easily
> > > be argued the other way, that it is easy to propose wholesale changes
> > > without much thought to what it would take to support existing users
> when
> > > there is no obligation to support them like a vendor may have.
> >
> >
> > How so? I will argue that the opposite is true. I don't want to repeat
> > things again and again. You know that I proposed an option based on 3.x
> > (and took the time to implement it) that would have required no change to
> > the user and not even a major version change. Now are debating major
> > version change, which no existing user is obligated to adopt, users can
> > continue with what they have and the vendor can continue to support 3.x.
> >
> The implementation, while did consider backward compatibility, provided a
> frozen version of the project and would require users to change their code
> in order to benefit from newer fixes and updates to existing operators.
> While appreciating the approach, I did note these shortcomings in the
> discussions in original discussion and the subsquent one and asked if a
> similar approach could be applied in a way that it would be possible to
> allow existing applications to benefit from future updates in the same
> major version without code changes. This is not trivial and when I saw
> there was no appetite to do this, I supported 4.x as the alternative.
Please refer to your original statement regarding wholesale changes. None
of the proposals under discussion propose wholesale changes without
considering existing users, that would be a false allegation.

> > Let's keep in mind that today there are not many users ("many" is
> > subjective). It is further a misrepresentation to claim that the
> community
> > wanting to make changes negatively affects users. I will argue the
> opposite
> > is true, the changes that are proposed will make it easier for new users
> to
> > adopt and build applications.
> >
> This is a very broad and incorrect interpretation of the original statement
> and it does not say or translate to "community
> wanting to make changes negatively affects users". It gives one
> interpretation of the original proposal of changing the package paths
> without providing wrappers that will remain compatible with older versions
> for at least some transitional period (no frozen older release is not the
> same). It is not what the community as a whole wants, so I wouldn't call it
> a community want either.

Should have been a separate paragraph. This part is actually not related to
your earlier statement regarding "community ask" but with regard to
repeated claims by a few that changes discussed negatively affect users.
That has already been addressed and there is nothing to back it up. As such
it is an invalid reason in voting -1.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message