Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-releng] recent failure in 3.1 builds due to Dali?

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!




From: Neil Hauge <neil.hauge@xxxxxxxxxx>
To: Webtools releng discussion list <wtp-releng@xxxxxxxxxxx>
Date: 08/20/2008 03:40 PM
Subject: Re: [wtp-releng] recent failure in 3.1 builds due to Dali?





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


Back to the top