[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-spec.committee] javax to jakarta poll
|
How do we specify an incremental change that doesn't break them at all?
-----Original Message-----
From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> On Behalf Of Alasdair Nottingham
Sent: 17 July 2019 13:33
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] javax to jakarta poll
I don’t agree with your characterization of Big Bang being about success of the platform moving forward and incremental because the individual APIs are more important than the platform. I see the debate as being more around what causes more hard to the platform moving forward, a change that breaks all users in the ecosystem at once, vs one that may not break them at all.
> On Jul 17, 2019, at 2:16 AM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
>
> This still seems like coming at it bottom up instead of top down.
>
> The reasons to prefer Big Bang have nothing to do with the pros and cons of moving any particular API, but rather the harm to the success of the platform of moving things piecemeal.
>
> The reason to prefer Incremental is because the success of the platform is irrelevant and all that matters is the individual APIs.
>
> I really don't see the point of collecting data about how many people want each one of the APIs to be moved. Either we're going to move them all, or we're going to move every one that we need to evolve when we need to evolve it. We're not going to refuse to move an API that needs to evolve just because not enough people want it to move.
>
> We've already got lots of feedback on Big Bang vs. Incremental. The key piece of data that we said we're still waiting for and that we still don't have is some evidence about how successful a binary compatibility implementation can be.
>
>
> David Blevins wrote on 7/16/19 9:44 PM:
>> I'm going to be very light on javax to jakarta for tomorrow's 8am pacific community call.
>>
>> I would, however, like 5 minutes of spec committee time on tomorrow's 9am call to collect some feedback on this poll we put together.
>>
>> - https://www.tomitribe.com/jakarta/ns/poll
>>
>> This is something we crafted just after I did the bytecode-level dependency tree analysis. It started with that in mind -- to give people a way to play with incremental thoughts or thoughts of big-bang with some deprecation or freezing. Primary a "calculator" that later turned into a poll.
>>
>> I'm more interested in if we think we can get some value out of it in this or a mutated form.
>>
>>
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>> 310-633-3852
>>
>>
>>
>> _______________________________________________
>> jakarta.ee-spec.committee mailing list
>>
>> jakarta.ee-spec.committee@xxxxxxxxxxx
>>
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>>
>> https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
>
> _______________________________________________
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee