Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Snapshot of APIs as of release 10.0 #1064

Merged
merged 2 commits into from Jan 3, 2019

Conversation

Projects
None yet
6 participants
@jtulach
Copy link
Contributor

commented Dec 31, 2018

After each release NetBeans should snapshot its APIs as described at the time of release paragraph. I've just applied the steps to version 10.0 in the git repository:

$ git checkout 10.0
$ ant clean; ant build
$ ant gen-sigtests-release # I had to fix the nbbuild/build.xml a bit to make this work
$ git stash
$ git checkout master
$ git pull
$ git checkout -b SnapshotOfAPIsAsOfRelease100
$ git stash pop
$ git add .
$ git commit -m "Snapshot of APIs as of 910bd74bf46d079e49925f702432c74d54ec705c (tag: 10.0-vc5, tag: 10.0, release100)"

You can find the result in this request. Ideally this process would be part of the release steps next time. CC @lkishalmi

description="Generates signature files into stable API modules directories"
>
<echo message="Generating signature files into stable API modules directories"/>

<pathconvert property="modules.fullpath" >

This comment has been minimized.

Copy link
@jtulach

jtulach Dec 31, 2018

Author Contributor

This target wasn't ready for the new, cluster based, structure of the repository.

This comment has been minimized.

Copy link
@jtulach

jtulach Jan 2, 2019

Author Contributor

All the APIs

This change has one, interesting side effect. The .sig files are now added to every module with some OpenIDE-Module-Public-Packages. Btw. that is the reason why there is so many new files added.

As a consequence we now have the same safety net for developing APIs all over the NetBeans code base. E.g. when we make an incompatible change in some APIs, we get a warning (as a failed travis or even local build) and we can take corrective actions.

Solving the friend dependency problem!?

With such infrastructure in place I wouldn't be afraid to open up (step by step and case by case) more modules with friend dependencies to public. Their API is still going to lack documentation, but if we open them and classify as under development, then at least our fellow developers will not have to play wild tricks to use them. Moreover, we'll be able to guarantee backward compatibility with released Apache NetBeans versions thanks to having the SigTest check in place.

@jtulach

This comment has been minimized.

Copy link
Contributor Author

commented Dec 31, 2018

There are many new files - looks like every module with some public packages got its snapshot.

@lkishalmi

This comment has been minimized.

Copy link
Contributor

commented Dec 31, 2018

@emilianbold

This comment has been minimized.

Copy link
Contributor

commented Jan 1, 2019

This is an area I know little of. Could we move the active page about this on http://netbeans.apache.org/wiki/ and explain more what this is all about.

I understand this would help us make sure we don't expose more than expected in terms of public API. Do we even call this on the build server?

When would I need to use this stuff on my machine?

@jtulach

This comment has been minimized.

Copy link
Contributor Author

commented Jan 2, 2019

I have no idea how to edit the so called "wiki". Wikis usually come with an edit button. I cannot find any at http://netbeans.apache.org/wiki/ Searching for "edit" text doesn't find anything useful either. Anyway, that is not a complain to be solved in this PR.

Yes, the API check is part of the travis build. See line 27. E.g. the build is supposed to fail when anyone makes an incompatible API change.

The aa8466e change makes this check part of single module build - when you press F11 in a module with some API - e.g. platform/openide.util.lookup and there is an incompatible change then the build fails.

@geertjanw

This comment has been minimized.

Copy link
Member

commented Jan 2, 2019

Jaroslav Tulach (jtulach) has access already to https://cwiki.apache.org/confluence/display/NETBEANS.

@jtulach

This comment has been minimized.

Copy link
Contributor Author

commented Jan 3, 2019

Can I get some approvals, please? Although these checks were already in for the NetBeans Platform and nobody found a problem, The extension of the API compatibility checks to all modules with an API deserves some agreement.

Re. Emilian's "make sure we don't expose more than expected" - actually no. These checks still allow you to add new elements to the API compatibly. These test only prevent us from removing APIs accidentally. E.g. They only check backward binary compatibility.

@lkishalmi

This comment has been minimized.

Copy link
Contributor

commented Jan 3, 2019

Well, it seems the method how this was done is documented. i see no reason not to integrate this into master. So I approve this change, if that means something.

@geertjanw geertjanw self-requested a review Jan 3, 2019

@geertjanw
Copy link
Member

left a comment

Great, approved.

@asfgit asfgit merged commit aa8466e into apache:master Jan 3, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.