That sounds reasonable. Clients can still get the benefits of range
checking in this scenario, assuming they know the rules on how
provisional changes will affect version numbers.
I'll make the appropriate changes in the version numbers tomorrow,
assuming that we don't hear a convincing argument against this policy
between now and then.
Neil
David M Williams wrote:
The more I think about it, I think
provisional
API changes should never be a major increase. After all, they are not
API!
The thing that should also be
written
down is that clients that use provisional API should specify their
pre-reqs
just as if they used non-API ... namely, a narrow minor field, so that
way there's not any risk of breaking if/when the provisional-API
changes. There may always be exceptions to the rule, but think that's
the
rule.
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
_______________________________________________
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
|