In this case we are probably changing one provisional API to another
provisional API. My thinking is that the provisional API should either
be removed, changed, or solidified (if it has been stable for a release
cycle, etc).
I think it is likely that for the API that will be changing, there may
not be many affected adopters, if any, but I guess I will try to make a
best guess on that, along with some research.
This will certainly be a tough one to sort out.
Neil
David M Williams wrote:
I'm not sure it's written down
either,
but normally we don't consider provisional API to official API as an
API
breaking change.
But I can see it argued either way,
but suspect there's a case-by-case aspect the decision. If we knew lots
of people
were using a provisional API, and we
really _broke_ that API while making if official, then client's code
would
not run with it, so
best to move up major version
number,
On the other extreme, if making a provisional API into an official
API just involved fixing
JavaDoc then best to not
automatically
break al clients and just make a minor version increase.
Good luck sorting this one out!
David,
All of the changes were made following the Eclipse Version Numbering
guidelines (at least my interpretation of them). The move from 1.x
to
2.0 was a result of breaking Provisional API changes. I guess this
raises the question of whether or not changes in Provisional API should
affect plugin version numbers. My thought was that they probably
should, since this would provide benefits to ourselves and adopters.
To recap the general situation, the current plan is to change/break
parts of the provisional API for the 2.1 release. Our thinking is
that
changing the API's sooner rather than later is better for everyone,
rather than letting the provisional API go stale for the 2.1. release
and then breaking further down the road. All changes are being
carefully tracked and will be posted for the M1 milestone (on the wiki)
for the community.
It is true (as you mention) that based on this change, the feature
number should be incremented in the major slot, and as a result, this
would move the feature number to 3.0. I guess this is the argument
for
not changing a plugin's major version number for Provisional API, in
that it does inflate the release number when these types of changes are
made.
What are your (and other's) thoughts on updating the plugin major field
for provisional API? I will pose this question to the dali-dev list
as
well. I don't think this is stated in any of our current policies.
Neil
David Williams wrote:
> Neil,
>
> If I understand this right, you changed a "1.x.x" version
of a bundle
> to "2.x.x"?
> That's not right ... is it? You are declaring breaking API changes
for
> your 2.1 release? Yikes!
>
> My guess is you just happened to notice these bundles were still
at
> the "1.x.x" level and they should have been incremented
last release
> to "2.x.x"?
>
> Unfortunately, its too late merely to be consistent :) ... Still
needs
> a +1 in (only) the minor field for a bundle that's adding
function,
> but not breaking. The +1 in the major field would be very breaking
to
> adopters.
>
> Features on the other hand, we've always treated different, and
they
> can have the "2.1" version through out.
>
> Of course, if you are declaring breaking API changes, then I
missed
> something, and your release would be called "3.x" (and the
bundle
> still incremented by only 1 in the major field, by convention ...
so
> you can never catch up :)
>
> Hope that helps,
>
>
> http://dev.eclipse.org/mhonarc/lists/wtp-releng/msg06816.html
>
>
> _______________________________________________
> wtp-releng mailing list
> wtp-releng@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-releng
_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng
_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng
|
