search

vert-x3 / eclipse-proposal-wip

Proposal for Eclipse Vert.x work in progress
3 stars 3 forks source link

Service releases #7

Open waynebeaton opened 8 years ago

waynebeaton commented 8 years ago

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 commented 8 years ago

The tag basically contains two files:

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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).