Hi,
  if there is a PR against h-services with a component set to a src-dep version, it's like a request for releasing the component, because I need to use that new feature that is not in that released version. What about CCing the component maintainer in that PR that you need a release and once it's released, change the src-dep version with a normal x.y.z.Final version? And only after that allow merging the PR.

This has the drawback that the PR may be blocked by the maintainer of the package until he releases. If we have a git bot similar to the MiQ one, it could spam the maintainers that there is a release request.

src-dep isn't perfect, but it's better than snapshots because of the reproducibility, otherwise it's almost the same to me, so it doesn't solve the releasing.

jk

On Wed, Aug 3, 2016 at 9:03 AM, Heiko W.Rupp <hrupp@redhat.com> wrote:
On 2 Aug 2016, at 21:34, Jay Shaughnessy wrote:

We are releasing h-services weekly to
- remove the pressure of cramming everything in, because the next
  release is far away
- allow to introduce new features and get them to public testing for
  feedback.

Of course one should not commit stuff that is knowingly broken.
But having it in h-services gives the soak time we need.

> PR can not be merged until commons is released.  I think it's
> reasonable to maybe use a src-dep in this situation, let commons
> perhaps get a few more changes during the week, and then release
> commons on Friday or Monday.

If there is a way to make sure everything is in good shape on
Monday evening (us time), *I* could also imagine using src-deps
for during the week.
The question is though: what happens if on Tuesday there are still
src-deps in h-services? Roll back to previous release? Cascade this?

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev