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.)
On 28/10/2015 15:24, Konstantin
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
understand the temptation to fudge the truth when it
comes to version numbers, but that doesn’t make it a
sound engineering practice.
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
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).
Original message -----
From: Konstantin Komissarchik
To: Ed Willink <ed@xxxxxxxxxxxxx>,
Subject: Re: [cross-project-issues-dev] DTP major
version bump for Neon
Date: Wed, Oct 28, 2015 9:45 AM
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
understand the temptation to fudge the truth when
it comes to version numbers, but that doesn’t make
it a sound engineering practice.
On 28/10/2015 13:13, Konstantin Komissarchik
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.
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6173 / Virus Database: 4455/10902 - Release