I will not repeat the points I made earlier regarding what I consider to be a breaking change. I will also not engage in a debate of what constitutes responsible API evolution. Suffice it to say that there is more than one valid approach. I don’t fault you
for how you are choosing to evolve EMF API. I don’t like being faulted for how I am choosing to evolve DTP API.
It seems like you feel that you must make a stand to try to force me to make this change, despite the minimal effort required on your part to uptake these changes. Fine. Please remove EMF ODA features from simrel aggregation so that I can see which project
I need to engage with next.
You definitely get my big thumbs up for stepping up to prevent starvation! Unfortunately you also get my big thumbs down for the big box of sugar coated candies that tend to make children sick. I don't doubt at all that your intentions are good. Also, as
the sole active committer on several projects, I can 100% empathize with your plight. I am also sensitive to the fact that no good deed goes unpunished: no matter how hard one tries to do good things, someone will rag on it. It's quite demoralizing so we
must learn to keep the negaholics at bay. You have my sympathy...
I do kindly, respectfully, and formally ask you to reconsider this disruptive move with DTP. Major version increments are justifiable only as they relate to breakage of API, which is not the case here. As participants on the release train and as leaders
of our development communities we should (must) carefully consider the impact of our actions. In this case, your actions are needlessly disruptive. They fly in the face of the documented processes, and do so over the objections of other community leaders.
Please, please, please reconsider...
For those who will rail about Konstantine's right to do as he believes best, please don't turn this into an issue about "rights". Yes of course Konstantine is free to break API. Let's not belabor that point. I too am free to break API for EMF, but I also
know that it's an absolute no go for my community, so I live with the burden imposed by the restriction and continue to work on the fundamentally thankless task of making sure that everything I do is not disruptive and therefore mostly unnoticed. Our community
must stand up for individual rights, but anarchy is no solution...
Note that I will not change the build for EMF ODA to build against the version-bumped DTP ODA bundles, so the EMF bundles will continue to exclude API breaking versions of DTP ODA. It's up to the DTP project to version their bundles semantically to reflect
true API breakage. If anyone has a problem with this, I regretfully offer to withdraw the EMF ODA feature from the train.
On 29/10/2015 5:05 PM, Erdal Karaca wrote:
I think Konstantin has adopted an orphan (that is about to starve).
By incrementing the major version Konstantin is expressing that he is going to invest a lot of (mental) energy to prevent the child from starvation.
@Konstantin: What do you need to keep the major version number as-is?
@Community: How else could you express your gratitude to Konstantin for what he is doing?
2015-10-28 19:20 GMT+01:00 Lars Vogel <lars.vogel@xxxxxxxxxxx>:
> So in this case Konstantin (and rest of the active DTP committers) should get our full support
I agree with Alexander. Kudos from my side to Konstantin for working
on the (almost) dead DTP components.
Content-wise I also think only the minor version needs increasement
with this change but it is also more important that DTP is available
at all in Neon.
I hope Konstantin does not get discouraged by this email storm and
leaves DTP so that is returns to be a dead project.
Best regards, Lars
On Wed, Oct 28, 2015 at 3:22 PM, Aleksandar Kurtakov
> ----- Original Message -----
>> From: "Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
>> To: "Ed Willink" <ed@xxxxxxxxxxxxx>,
>> Sent: Wednesday, 28 October, 2015 3:44:54 PM
>> Subject: Re: [cross-project-issues-dev] DTP major version bump for Neon
>> I gave the justification several times.
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit