9:38 a.m.
Team,
It seems there's a small confusion about src-deps and H-Services.
H-Services is a module that is released every week, given that there's
at least one new commit since the last release.
The src-deps plugin is very helpful for our daily work, as it allows us
to use a given commit as a dependency for our modules, but it's not
appropriate for released artifacts, as it kinda breaks the stability
promise that "a released artifact uses only released artifacts" that is
common on Maven. Besides, I believe there were problems in the past
between src-deps and the maven-release-plugin.
So, avoid sending PRs with src-deps to H-Services. If for some reason
you really need to, switch it to a proper version before Tuesday morning.
- Juca.
9:34 p.m.
The problem with this it makes it hard to let devs have some soak time
with a change without making releases for every commit. For example,
right now I have a PR for commons and a change in hawkular-services that
depends on it. In this scheme the services 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.
On 8/2/2016 3:38 AM, Juraci Paixão Kröhling wrote:
Team,
It seems there's a small confusion about src-deps and H-Services.
H-Services is a module that is released every week, given that there's
at least one new commit since the last release.
The src-deps plugin is very helpful for our daily work, as it allows us
to use a given commit as a dependency for our modules, but it's not
appropriate for released artifacts, as it kinda breaks the stability
promise that "a released artifact uses only released artifacts" that is
common on Maven. Besides, I believe there were problems in the past
between src-deps and the maven-release-plugin.
So, avoid sending PRs with src-deps to H-Services. If for some reason
you really need to, switch it to a proper version before Tuesday morning.
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
8:09 a.m.
On 02.08.2016 21:34, Jay Shaughnessy wrote:
The problem with this it makes it hard to let devs have some soak
time
with a change without making releases for every commit. For example,
right now I have a PR for commons and a change in hawkular-services that
depends on it. In this scheme the services 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.
That's a case where I think using src-deps makes sense, but this src-dep
should be cleared by Tuesday.
Besides: releasing commons is very easy. If you need a release on
commons, just ask me, or go ahead and click on "Perform Maven Release"
on Jenkins at Torii.
- Juca.
9:03 a.m.
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?
12:06 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:25 p.m.
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?
Right, this is really the issue with allowing src-dep. Personally, I
think we can survive this issue with just a bit of personal
responsibility. If you are responsible for the src-dep being in master
then you are responsible for ensuring it doesn't block the release. So,
by Friday, or Monday at the latest, either get rid of it yourself by
doing a release of the component and updating the pom, or, find someone
to do it. So, for the scenario I originally presented, I'll actually
have PR for services with a commons src-dep. Before the release I'll
ensure services is based on a release.
10:39 a.m.
On 3 Aug 2016, at 15:25, Jay Shaughnessy wrote:
responsibility. If you are responsible for the src-dep being in
master
then you are responsible for ensuring it doesn't block the release. So,
by Friday, or Monday at the latest, either get rid of it yourself by
doing a release of the component and updating the pom, or, find someone
And todays release build showed that this is not feasible,
as a src-dep indeed remained in master and broke the
release build.
2:46 p.m.
Hmmm, I seem to have egg on my face, I think that was my doing with
commons. Fine then, no src-deps.
On 8/9/2016 4:39 AM, Heiko W.Rupp wrote:
On 3 Aug 2016, at 15:25, Jay Shaughnessy wrote:
> responsibility. If you are responsible for the src-dep being in master
> then you are responsible for ensuring it doesn't block the release. So,
> by Friday, or Monday at the latest, either get rid of it yourself by
> doing a release of the component and updating the pom, or, find someone
And todays release build showed that this is not feasible,
as a src-dep indeed remained in master and broke the
release build.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9:38 p.m.
Hello,
I agree with the comments on the src-deps plugin. In fact I am in favor of
going on step further and rejecting PRs using it.
At the same time can we reinstate the use of SNAPSHOTs dependencies?
Thank you,
Stefan Negrea
On Tue, Aug 2, 2016 at 2:38 AM, Juraci Paixão Kröhling <
jpkroehling(a)redhat.com> wrote:
Team,
It seems there's a small confusion about src-deps and H-Services.
H-Services is a module that is released every week, given that there's
at least one new commit since the last release.
The src-deps plugin is very helpful for our daily work, as it allows us
to use a given commit as a dependency for our modules, but it's not
appropriate for released artifacts, as it kinda breaks the stability
promise that "a released artifact uses only released artifacts" that is
common on Maven. Besides, I believe there were problems in the past
between src-deps and the maven-release-plugin.
So, avoid sending PRs with src-deps to H-Services. If for some reason
you really need to, switch it to a proper version before Tuesday morning.
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
10:08 p.m.
Of course snapshots would work for my scenario as well. I had
discounted the possibility but I guess it's a fair question for short
periods of time. As long as nothing blocks the weekly release it seems
reasonable. But i can also live with bunches of releases if we always
have people with privs to build each component. I know Lucas or I can
typically release Alerting.
On 8/2/2016 3:38 PM, Stefan Negrea wrote:
Hello,
I agree with the comments on the src-deps plugin. In fact I am in
favor of going on step further and rejecting PRs using it.
At the same time can we reinstate the use of SNAPSHOTs dependencies?
Thank you,
Stefan Negrea
On Tue, Aug 2, 2016 at 2:38 AM, Juraci Paixão Kröhling
<jpkroehling(a)redhat.com <mailto:jpkroehling@redhat.com>> wrote:
Team,
It seems there's a small confusion about src-deps and H-Services.
H-Services is a module that is released every week, given that there's
at least one new commit since the last release.
The src-deps plugin is very helpful for our daily work, as it
allows us
to use a given commit as a dependency for our modules, but it's not
appropriate for released artifacts, as it kinda breaks the stability
promise that "a released artifact uses only released artifacts"
that is
common on Maven. Besides, I believe there were problems in the past
between src-deps and the maven-release-plugin.
So, avoid sending PRs with src-deps to H-Services. If for some reason
you really need to, switch it to a proper version before Tuesday
morning.
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org <mailto:hawkular-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
10:21 p.m.
I know there were some issues in the past with SNAPSHOT artifacts in
general. Can we revisit that in the context of Hawkular Services since a
lot changed in the past few months?
The cascading dependency changes was not at all addressed, mitigated, or
resolved by src-dep plugin. Also, a ton of releases per week due to
cascading effect is really not the solution. Now that the consumer is not
another Java project we can take the time to rethink how we release stuff
in general?
Thank you,
Stefan Negrea
On Tue, Aug 2, 2016 at 3:08 PM, Jay Shaughnessy <jshaughn(a)redhat.com> wrote:
Of course snapshots would work for my scenario as well. I had discounted
the possibility but I guess it's a fair question for short periods of
time. As long as nothing blocks the weekly release it seems reasonable.
But i can also live with bunches of releases if we always have people with
privs to build each component. I know Lucas or I can typically release
Alerting.
On 8/2/2016 3:38 PM, Stefan Negrea wrote:
Hello,
I agree with the comments on the src-deps plugin. In fact I am in favor of
going on step further and rejecting PRs using it.
At the same time can we reinstate the use of SNAPSHOTs dependencies?
Thank you,
Stefan Negrea
On Tue, Aug 2, 2016 at 2:38 AM, Juraci Paixão Kröhling <
jpkroehling(a)redhat.com> wrote:
> Team,
>
> It seems there's a small confusion about src-deps and H-Services.
> H-Services is a module that is released every week, given that there's
> at least one new commit since the last release.
>
> The src-deps plugin is very helpful for our daily work, as it allows us
> to use a given commit as a dependency for our modules, but it's not
> appropriate for released artifacts, as it kinda breaks the stability
> promise that "a released artifact uses only released artifacts" that is
> common on Maven. Besides, I believe there were problems in the past
> between src-deps and the maven-release-plugin.
>
> So, avoid sending PRs with src-deps to H-Services. If for some reason
> you really need to, switch it to a proper version before Tuesday morning.
>
> - Juca.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
_______________________________________________
hawkular-dev mailing
listhawkular-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
8:19 a.m.
On 02.08.2016 22:21, Stefan Negrea wrote:
I know there were some issues in the past with SNAPSHOT artifacts in
general. Can we revisit that in the context of Hawkular Services since a
lot changed in the past few months?
No, snapshots aren't a solution, as they are not predictable at all.
Think about the snapshot resolution during the build of a PR. How would
that work? Also, how does it solve the problem with H-Services? It doesn't.
From my original email:
The src-deps plugin is very helpful for our daily work, as it allows
us
to use a given commit as a dependency for our modules, but it's not
appropriate for released artifacts, as it kinda breaks the stability
promise that "a released artifact uses only released artifacts" that is
common on Maven.
Snapshots have the same problems, plus a couple of problems of its own.
Snapshots make sense only for modules that can be resolved in the same
project tree, like submodules, or for local development. For anything
else, you'd be bringing one element that is not desirable at all: doubt.
"Which snapshot did this build use?" is never a question we should be
asking ourselves.
- Juca.
2823
days inactive
2830
days old
12 comments
5 participants
participants (5)
-
Heiko W.Rupp -
Jay Shaughnessy -
Jiri Kremser -
Juraci Paixão Kröhling -
Stefan Negrea