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 02:21:14 GMT
I think you have been consistent in your position. However, we cannot claim
something is a community concern unless that is the case.

On Sun, Aug 27, 2017 at 5:37 PM, 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.
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.

> Yes nothing would prevent contributors from submitting the changes to
> master simultaneously and should be encouraged. I am trying to figure out
> the best way to accomodate the ask where the contributors be not required
> to do so when they cannot or don't want to do so and to not block those
> contributions. I don't know if this will change the -1 votes but hoping
> folks can discuss this.

If it is purely a vendor interest and not a community interest, then it is
also possible to apply such changes to the fork. This has been done in the
past. I see a risk that we are discussing something that may not even
become relevant, looking at current contributions and type of changes.

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