Re: [wtp-releng] recent failure in 3.1 builds due to Dali?

[David M Williams <david_williams@xxxxxxxxxx>]

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.

From:	Neil Hauge <neil.hauge@xxxxxxxxxx>
To:	Webtools releng discussion list <wtp-releng@xxxxxxxxxxx>
Date:	08/20/2008 04:15 PM
Subject:	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
  
_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng