Hi
Perhaps you can just follow the community experience.
You don't have to change your BREE at all, but you will still impose a
Java 8 BREE on your Neon customers, since the platform already has a Job
component that requires Java 8. I am not aware of anyone suggesting that
this BREE change requires the platform move to e5.
I also write from direct experience. When I took over OCL, I found that
UML was taking a major version change requiring an OCL move from version
2.x to 3.x. I mistakenly thought that the previous failure of other
plugins to move from 1.x to 2.x was a historical mistake, so I corrected
it. Everything became nice and simple; 3.x all round. Except that client
builds broke. With the benefit of experience I now know that the 1.x
plugins could still be 1.x many years later and I need never have
inflicted the pain on my clients. (Belated apologies to them.)
Regards
Ed Willink
On 28/10/2015 15:24, Konstantin Komissarchik wrote:
> potentially no impact on most consumers of your API
And here lies the crux of our disagreement. I take an absolute
position on this issue. Potentially not breaking a consumer with an
existing DTP installation is not the same as not breaking them. Any
other position throws into question why we even bother having a
versioning convention. By definition, any API change can be
characterized as potentially having no impact.
- Konstantin
*From: *John Arthorne
*Sent: *Wednesday, October 28, 2015 8:07 AM
*To: *[email protected]
*Subject: *Re: [cross-project-issues-dev] DTP major version bump for Neon
> I understand the temptation to fudge the truth when it comes to version
numbers, but that doesn’t make it a sound engineering practice.
You appear to be the first person to claim that making version numbers
reflect changes to runtime dependencies is sound engineering
practice. Even Java itself did not update its major version with Java
8 (which is officially version 1.8 at the JVM level). Changes to your
dependencies have no direct impact on your API, and potentially no
impact on most consumers of your API. A consumer of your bundle may
already have a dependency on Java 8 (or whatever the case may be), and
therefore could not possibly be impacted by your change. By updating
your BREE, you have ensured that your bundle will not even be loaded
by OSGi in a runtime using Java 7 or earlier, which is already a
strong enough hint to any consumer impacted by this change. Updating
the bundle version number as well offers absolutely no benefit.
I will agree with Alex, that as the person doing the work you have the
right to make these changes, however unjustified. The consumer
community will have to react accordingly (by updating manifests,
contributing to the project, removing the dependency, forking, etc).
John
----- Original message -----
From: Konstantin Komissarchik <[email protected]>
Sent by: [email protected]
To: Ed Willink <[email protected]>,
"[email protected]"
<[email protected]>
Cc:
Subject: Re: [cross-project-issues-dev] DTP major version bump for
Neon
Date: Wed, Oct 28, 2015 9:45 AM
I gave the justification several times. You are choosing to
disregard it. Java API is not bundle’s sole API. I don’t consider
a restriction in requirements a compatible change. DTP 2 is
certainly not a drop-in replacement for DTP 1.12 and the version
numbering truthfully communicates that fact.
I understand the temptation to fudge the truth when it comes to
version numbers, but that doesn’t make it a sound engineering
practice.
- Konstantin
*From: *Ed Willink
*Sent: *Wednesday, October 28, 2015 6:29 AM
*To: *[email protected]
*Subject: *Re: [cross-project-issues-dev] DTP major version bump
for Neon
On 28/10/2015 13:13, Konstantin Komissarchik wrote:
I have no specific plans re ODA’s Java API.
So absolutely no justification for a change then. There is no need
for all plugins to bump together. It is cosmetically nice to see
all plugins with the same version, but it just isn't tenable long
term.
For instance many OCL plugins remain at 3.x although those that
have been affected by UML major changes have moved to 4.x and 5.x.
Inflicting a major change on clients is not a bit of a pain, it is
a major pain, particularly for those clients that are stable and
consequently have minimal maintenance teams. In some cases useful
but unmaintained tools, such as UML2 Tools, are killed by the
major version change.
Regards
Ed Willink
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2015.0.6173 / Virus Database: 4455/10902 - Release Date: 10/28/15
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
