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

Service releases #7

Open
waynebeaton opened this issue Jan 19, 2016 · 4 comments
Open

Service releases #7

waynebeaton opened this issue Jan 19, 2016 · 4 comments

Comments

@waynebeaton
Copy link

However, Bower requires a Git repository on which tags are “manually” created after the
release. The tag contains an updated version of the vert.x event bus client (Socks) and
updated metadata. It is not known yet if such a process is compatible with Eclipse guidelines.

The implication is that changes are introduced with these tags. If these changes are bug fixes or otherwise minor changes that do not introduce new functionality, then we would regard them as "service releases" which to not require any sort of formal review or ceremony.

If the changes introduce significant new functionality or change APIs, then a more formal release review will be required.

@cescoffier
Copy link
Member

The tag basically contains two files:

  • the eventbus client
  • a bower.json file.

The js file is actually a copy from a file from vertx-web (a genuine copy, no modification, even the name is not change). The copied file is:
https://github.com/vert-x3/vertx-web/blob/master/vertx-web/src/client/vertx-eventbus.js.

So this file would have been analyzed during the release process.

The bower.json file is a template: https://github.com/vert-x3/vertx-bus-bower/blob/master/src/main/bower/bower.json

(This template would have to be modified to mention Eclipse of course)

So, in this case, does the release (the creation of the tag) need a formal release review ? We cannot create the tag beforehand (as it would push the file on bower).

@cescoffier
Copy link
Member

The same question would apply when we deploy our artifacts on Homebrew or GVM. It's basically release artifacts (that has followed the formal release review), but with "metadata".

@waynebeaton
Copy link
Author

Projects must engage in a release review for any product that includes new functionality or breaks APIs. Just packaging existing products using different technologies does not require a formal review. The GitHub notion of a release is separate from the Eclipse Project notion of a release. I recommend that we synchronize the naming of them as much as possible to avoid confusion.

I'm a little concerned that we're not connecting, or are maybe talking about two different things.

As part of the release process, an Eclipse project is required to engage in a review before disseminating their products to the broader community. Interim "milestone" releases are generally intended for a more restricted audience, primarily for testing and feedback leading up to the formal release.

Releases and release reviews are described in the Eclipse Project Handbook https://www.eclipse.org/projects/handbook/#release

@cescoffier
Copy link
Member

I read the link you sent. So there is no problem as everything we make "available" would have been checked. So I think we can close this issue (I let you decide if you want more details).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants