1:41 a.m.
Right now I've seen version strings as 1.0-SNAPSHOT, 1.0.0-SNAPSHOT and
1.0.0.Alpha1-SNAPSHOT.
We need to come to a consensus and be consistent. From what I understand, people prefer:
1.0.0-SNAPSHOT
I would like to go through all our components and change their versions to be that. It
would be nice to have our first distro release at least be consistent in naming of
versions.
In addition, its getting annoying with having to rely on release versions of parent pom.
I'm again waiting on release 8 because I added a new maven plugin to the parent. We
should move every pom over to use 8-SNAPSHOT so we can keep picking up changes. We are
moving fast, and its slowing us down (well, me down for one) because we now have poms that
need parent pom v6 and v7 and my stuff is waiting on 8. We can release when we get some
kind of product out.
There is also discussion that lucas k brought up - why not have version string for parent
pom follow the same convention as everything else (that is, why not make 8-SNAPSHOT to be
1.0.0-SNAPSHOT instead?) I'll let others decide that later. I agree we should at least
be consistent in version format for everything.
2:40 a.m.
Hi *, inline...
On 02/24/2015 05:41 PM, John Mazzitelli wrote:
Right now I've seen version strings as 1.0-SNAPSHOT,
1.0.0-SNAPSHOT
and 1.0.0.Alpha1-SNAPSHOT.
We need to come to a consensus and be consistent. From what I
understand, people prefer:
1.0.0-SNAPSHOT
I would like to go through all our components and change their
versions to be that. It would be nice to have our first distro
release at least be consistent in naming of versions.
Some theory in favor of adding a qualifier such as Alpha[n], Beta[n],
CR[n] and Final : https://developer.jboss.org/wiki/JBossProjectVersioning
In addition, its getting annoying with having to rely on release
versions of parent pom. I'm again waiting on release 8 because I
added a new maven plugin to the parent.
Please do not commit your own changes to the parent.
https://github.com/hawkular/hawkular-parent-pom#how-to-contribute
We should move every pom over
to use 8-SNAPSHOT so we can keep picking up changes. We are moving
fast, and its slowing us down (well, me down for one) because we now
have poms that need parent pom v6 and v7 and my stuff is waiting on
8. We can release when we get some kind of product out.
Do not do that. Introducing SNAPSHOT dependencies makes builds
irreproducible and unreliable. You never know which revision you get
from the SNAPSHOTs repo. Looking at today's #hawkular logs, at least
mazz, mtho11 and stefan_n know what I am speaking about.
There is also discussion that lucas k brought up - why not have
version string for parent pom follow the same convention as
everything else (that is, why not make 8-SNAPSHOT to be
1.0.0-SNAPSHOT instead?)
It would be quite hard to find the criteria for deciding when to
increase major, minor or micro in parent.
As far as the parent contained just maven plugins, there was no
backwards compatibility in game. I admit it is quite different now that
we manage dependencies there. But I see no way how semantic versioning
could work with the parent either.
-- Peter
I'll let others decide that later. I agree
we should at least be consistent in version format for everything.
_______________________________________________ hawkular-dev mailing
list hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
4:01 a.m.
> In addition, its getting annoying with having to rely on
release
> versions of parent pom. I'm again waiting on release 8 because I
> added a new maven plugin to the parent.
Please do not commit your own changes to the parent.
https://github.com/hawkular/hawkular-parent-pom#how-to-contribute
Unless I misunderstand how this is supposed to work, this would mean I not only would have
to wait for someone to peer review and merge my PR, but then I also have to wait for
someone to take the time and push a release, and then wait for it to get into maven
central because using it. And all I added was the xml maven plugin definition to the
parent pom.
The reason why we had build problems this morning is because I screwed up the kettle build
- and I was easily able to fix it by just committing stuff to the bus repo's master
branch - travis and nexus picked up the snapshot builds easily and we were back running
because everything else was picking up snapshots. I would have slit my wrists if I had to
commit to the bus repo, wait for someone to merge it, up the version number, release it,
then go to the kettle repo, up the version number of the bus artifacts, create PR/merge
it, and release it. People would still be waiting for a good kettle build :)
5:45 a.m.
On 02/24/2015 08:01 PM, John Mazzitelli wrote:
>> In addition, its getting annoying with having to rely on
release
>> versions of parent pom. I'm again waiting on release 8 because I
>> added a new maven plugin to the parent.
>
> Please do not commit your own changes to the parent.
> https://github.com/hawkular/hawkular-parent-pom#how-to-contribute
Unless I misunderstand how this is supposed to work, this would mean
I not only would have to wait for someone to peer review and merge my
PR, but then I also have to wait for someone to take the time and
push a release, and then wait for it to get into maven central
because using it. And all I added was the xml maven plugin definition
to the parent pom.
No, you would not necessarily have to wait for all of that. It is only
public durable branches that should not depend on snapshots. Everybody
is free to depend on snapshots in his working copy and/or topic branches.
If this fast dependency propagation is so important, we should setup
some kind of CI that will release an integrate timestamp-qualified
artifacts daily or even more often. With that, the builds would be
deterministic.
The reason why we had build problems this morning is because I
screwed up the kettle build
Sorry, I may have misinterpreted today's symptoms.
-- P
- and I was easily able to fix it by just
committing stuff to the bus repo's master branch - travis and nexus
picked up the snapshot builds easily and we were back running because
everything else was picking up snapshots. I would have slit my wrists
if I had to commit to the bus repo, wait for someone to merge it, up
the version number, release it, then go to the kettle repo, up the
version number of the bus artifacts, create PR/merge it, and release
it. People would still be waiting for a good kettle build :)
_______________________________________________ hawkular-dev mailing
list hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
10:31 p.m.
On Tuesday, February 24, 2015 21:45:45 Peter Palaga wrote:
On 02/24/2015 08:01 PM, John Mazzitelli wrote:
>>> In addition, its getting annoying with having to rely on release
>>> versions of parent pom. I'm again waiting on release 8 because I
>>> added a new maven plugin to the parent.
>>
>> Please do not commit your own changes to the parent.
>> https://github.com/hawkular/hawkular-parent-pom#how-to-contribute
>
> Unless I misunderstand how this is supposed to work, this would mean
> I not only would have to wait for someone to peer review and merge my
> PR, but then I also have to wait for someone to take the time and
> push a release, and then wait for it to get into maven central
> because using it. And all I added was the xml maven plugin definition
> to the parent pom.
No, you would not necessarily have to wait for all of that. It is only
public durable branches that should not depend on snapshots.
Right there! We don't have public durable branches now, IMHO ;)
Everybody
is free to depend on snapshots in his working copy and/or topic branches.
If this fast dependency propagation is so important, we should setup
some kind of CI that will release an integrate timestamp-qualified
artifacts daily or even more often. With that, the builds would be
deterministic.
> The reason why we had build problems this morning is because I
> screwed up the kettle build
Sorry, I may have misinterpreted today's symptoms.
-- P
> - and I was easily able to fix it by just
> committing stuff to the bus repo's master branch - travis and nexus
> picked up the snapshot builds easily and we were back running because
> everything else was picking up snapshots. I would have slit my wrists
> if I had to commit to the bus repo, wait for someone to merge it, up
> the version number, release it, then go to the kettle repo, up the
> version number of the bus artifacts, create PR/merge it, and release
> it. People would still be waiting for a good kettle build :)
> _______________________________________________ hawkular-dev mailing
> list hawkular-dev(a)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:11 p.m.
On 02/25/2015 02:31 PM, Lukas Krejci wrote:
On Tuesday, February 24, 2015 21:45:45 Peter Palaga wrote:
> On 02/24/2015 08:01 PM, John Mazzitelli wrote:
>>>> In addition, its getting annoying with having to rely on release
>>>> versions of parent pom. I'm again waiting on release 8 because I
>>>> added a new maven plugin to the parent.
>>>
>>> Please do not commit your own changes to the parent.
>>> https://github.com/hawkular/hawkular-parent-pom#how-to-contribute
>>
>> Unless I misunderstand how this is supposed to work, this would mean
>> I not only would have to wait for someone to peer review and merge my
>> PR, but then I also have to wait for someone to take the time and
>> push a release, and then wait for it to get into maven central
>> because using it. And all I added was the xml maven plugin definition
>> to the parent pom.
>
> No, you would not necessarily have to wait for all of that. It is only
> public durable branches that should not depend on snapshots.
Right there! We don't have public durable branches now, IMHO ;)
You joker :D -- P
> Everybody
> is free to depend on snapshots in his working copy and/or topic branches.
>
> If this fast dependency propagation is so important, we should setup
> some kind of CI that will release an integrate timestamp-qualified
> artifacts daily or even more often. With that, the builds would be
> deterministic.
>
>> The reason why we had build problems this morning is because I
>> screwed up the kettle build
>
> Sorry, I may have misinterpreted today's symptoms.
> -- P
>
>> - and I was easily able to fix it by just
>> committing stuff to the bus repo's master branch - travis and nexus
>> picked up the snapshot builds easily and we were back running because
>> everything else was picking up snapshots. I would have slit my wrists
>> if I had to commit to the bus repo, wait for someone to merge it, up
>> the version number, release it, then go to the kettle repo, up the
>> version number of the bus artifacts, create PR/merge it, and release
>> it. People would still be waiting for a good kettle build :)
>> _______________________________________________ hawkular-dev mailing
>> list hawkular-dev(a)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
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
10:36 p.m.
Am 24.02.2015 um 20:01 schrieb John Mazzitelli
<mazz(a)redhat.com>:
to merge it, up the version number, release it, then go to the kettle repo, up the
version number of the bus artifacts, create PR/merge it, and release it. People would
still be waiting for a good kettle build :)
Actually this morning (MET) Travis did not have a good build, because a not-yet-built
dependency was
introduced and hawkular/kettle was not finding it.
This seems to finally build again after kicking all the individual CI builds in correct
order.
Asking that we need to be able to apply duct tape all over the mistakes we made a few
minutes ago
when not following the more strict rules that could have prevent havoc in the first place,
may be a flawed argument.
I like the absolute freedom to be able to just commit what I want.
On the other hand I make mistakes and it is good that peer review and CI can catch them
before they hit master.
What is wrong in a PR to say depends on foo-M123 and bar-M245 ?
Or that Hawkular-1.0.0.GA.Super.Duper.Cool will internally depend on metrics-M345 and
inventory-M23 ?
Also with the idea of "release early, release often" and "make small
customer visible changes", master and
the PRs should not diverge too much, but will allow PR-builds to depend on a defined set
of dependencies.
Today when you say "depends on bla-SNAPSHOT", you don't know what version of
bla-SNAPSHOT will
be used in CI (or later even in CD ).
Instead of using Milestones (Mxxx) we can also introduce/use timestamped snapshots.
And Lukas: Now suppose you change the inventory-implementation to the future branch, which
has a different REST-api, different domain objects and a few other things. Once that hits
master, every other component depending on Inventory (UI , Pinger, ??) will
fail as they just pull the new snapshot and have compile or runtime failures. With some
"luck" you only see that after someone assembles the Kettle and runs it.
Here allowing the UI / Pinger to still build/run against inventory-current will help to
transition them over to the new api, as the Kettle will still build and work. And only if
the Pinger dev explicitly says "Now I want inventory-future and have changed my
code", that breakage is prevented. And yes, I know this still requires the 3
components being introduced in lock-step, which could be prevented by content-negotiation,
which we need to introduce once the existing apis have stabilized.
10:47 p.m.
On Thursday, February 26, 2015 14:36:56 Heiko W.Rupp wrote:
> Am 24.02.2015 um 20:01 schrieb John Mazzitelli
<mazz(a)redhat.com>:
> to merge it, up the version number, release it, then go to the kettle
> repo, up the version number of the bus artifacts, create PR/merge it, and
> release it. People would still be waiting for a good kettle build :)
Actually this morning (MET) Travis did not have a good build, because a
not-yet-built dependency was introduced and hawkular/kettle was not finding
it.
This seems to finally build again after kicking all the individual CI builds
in correct order.
Asking that we need to be able to apply duct tape all over the mistakes we
made a few minutes ago when not following the more strict rules that could
have prevent havoc in the first place, may be a flawed argument.
I like the absolute freedom to be able to just commit what I want.
On the other hand I make mistakes and it is good that peer review and CI
can catch them before they hit master.
What is wrong in a PR to say depends on foo-M123 and bar-M245 ?
Or that Hawkular-1.0.0.GA.Super.Duper.Cool will internally depend on
metrics-M345 and inventory-M23 ?
Also with the idea of "release early, release often" and "make small
customer visible changes", master and the PRs should not diverge too much,
but will allow PR-builds to depend on a defined set of dependencies. Today
when you say "depends on bla-SNAPSHOT", you don't know what version of
bla-SNAPSHOT will be used in CI (or later even in CD ).
Instead of using Milestones (Mxxx) we can also introduce/use timestamped
snapshots.
And Lukas: Now suppose you change the inventory-implementation to the future
branch, which has a different REST-api, different domain objects and a few
other things. Once that hits master, every other component depending on
Inventory (UI , Pinger, ??) will fail as they just pull the new snapshot
and have compile or runtime failures. With some "luck" you only see that
after someone assembles the Kettle and runs it. Here allowing the UI /
Pinger to still build/run against inventory-current will help to transition
them over to the new api, as the Kettle will still build and work. And only
if the Pinger dev explicitly says "Now I want inventory-future and have
changed my code", that breakage is prevented. And yes, I know this still
requires the 3 components being introduced in lock-step, which could be
prevented by content-negotiation, which we need to introduce once the
existing apis have stabilized.
Hence my proposal to go back to 0.y.z-SNAPSHOT versioning scheme and actually
raise the version when making a breaking change. Semver (which I think would
be a good thing to follow) allows for 0. versions to make breaking changes,
because they are made before the first stable release - 1.0.0.
To recap - I find it to be a real issue that people have to wait for a new
versioned build for potentially every bugfix we make in order to "align" the
components (and this early in dev, we are misaligned all the time because of
the pace of development on all fronts). At the same time, you are right about
api-breaking changes causing havoc, of course.
So to solve "my" issue, I propose using snapshot builds. To solve
"your"
issue, I propose to actually increase the version on every breaking change.
But I guess depending on timed snapshots can achieve the same goal, only IMHO
less elegantly, because with them you don't know if a breaking change was
introduced or not.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
11:43 p.m.
Hence my proposal to go back to 0.y.z-SNAPSHOT versioning scheme and
actually
raise the version when making a breaking change.
That's exactly how it should be done. SNAPSHOTSs until we hit breaking changes, then
releases.
Of course, in our current stage of development, isn't everything a breaking change? :)
Can you imagine what Jay and Heiko would have had to go through yesterday if they had to
bump up version numbers to their maven modules and push a "release" for
everything they did while trying to get that metric data JSON to flow correctly between
their pinger and alerts components (and I think it involved inventory)? It would have been
unbearable and useless.
Here's another example, and why I have a problem using release versions always - this
is just to give another actual instance that happened. Yesterday, Libor published for me
some enhancements and fixes to his nice Wildfly extension maven plugin. I bumped up the
plugin version in the parent pom so I can use it. I didn't realize snapshots of the
parent pom weren't yet published. So I completely foo-bared the builds. I was supposed
to have created a PR to the parent pom, waited for that PR to be peer-reviewed and merged
to master, waited for someone to bump up the parent-pom version number, do a mvn release
on the parent pom, and once it was published, only then could I have gone back to my own
pom, bump up its parent-pom version, THEN use Libor's new maven features.
All to be able to use a new version of a maven plugin.
Surely, that can't be what we want people to go through for such a trivial change.
Now, if some API changes (say, someone wants to bump up a <dependency> in parent pom
to a new major or major.minor version that changes to incompatible API changes, OR someone
changes a maven plugin to a version that isn't compatible with older versions) then
ABSOLUTELY we need to go through that new version/release cycle for reasons that were
brought up earlier.
But not for trivial changes that don't have such effects. That's where SNAPSHOT
helps us move fast.
As for Travis, that's another issue :)
11:47 p.m.
Am 26.02.2015 um 15:43 schrieb John Mazzitelli
<mazz(a)redhat.com>:
All to be able to use a new version of a maven plugin.
You could have used that new version in the kettle pom (where this plugin is actually
needed?) and only release
this now. Then have the version added to the root-pom and when this is available removed
in kettle.
11:54 p.m.
You could have used that new version in the kettle pom (where this
plugin is
actually needed?) and only release
this now. Then have the version added to the root-pom and when this is
available removed in kettle.
It was actually in the nest distro module, not kettle.
But that is what I ended up doing! But you realize that now you are asking people to have
to remember to go back and remove code when a release is available (where this code was
just a temporary fix that I had to add to work around this annoying workflow - so you just
made it more annoying to have to remember to go back and take out code I didn't want
to add in the first place :). And will I remember to do that once the release is made??
And BTW it's against "convention" to use <versions> in our poms, no?
We shouldn't be overriding <versions> - we should be just referring to
<artifactId> and letting the parent pom decide what versions to use so we all use
the same versions.
In any event, yes, that is what I ended up doing. Which reminds me, I don't think I
did remove my temporary <version> fix - I think I need to go do that :)
12:06 a.m.
On 02/26/2015 03:54 PM, John Mazzitelli wrote:
> You could have used that new version in the kettle pom (where
this plugin is
> actually needed?) and only release
> this now. Then have the version added to the root-pom and when this is
> available removed in kettle.
It was actually in the nest distro module, not kettle.
But that is what I ended up doing! But you realize that now you are asking people to have
to remember to go back and remove code when a release is available (where this code was
just a temporary fix that I had to add to work around this annoying workflow - so you just
made it more annoying to have to remember to go back and take out code I didn't want
to add in the first place :). And will I remember to do that once the release is made??
And BTW it's against "convention" to use <versions> in our poms, no?
No, put them at the most top level of your project.
We shouldn't be overriding <versions> - we should be just
referring to <artifactId> and letting the parent pom decide what versions to use so
we all use the same versions.
In any event, yes, that is what I ended up doing. Which reminds me, I don't think I
did remove my temporary <version> fix - I think I need to go do that :)
Don't put all versions in the POM/BOM for reasons I already explained a
couple of times ;)
Thomas
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
12:12 a.m.
Don't put all versions in the POM/BOM for reasons I already
explained a
couple of times ;)
(just so I am clear, this isn't a BOM that people are importing - this is discussing
the parent POM to our components).
But if we don't have a common parent pom, we can't ensure everyone uses the same
version of dependencies and plugins (which is why Peter created the parent pom in the
first place). Otherwise, it will end up some modules will be using version "1"
but others using version "2" others version "3", etc. and then things
get all out of sync as time moves forward and everyone wants to use their own versions and
don't coordinate with everyone else.
We need a parent pom to ensure we all are on the same page and our builds all use the same
dependencies/plugins across components (ESPECIALLY if we are to have an MVP where
everything runs inside a single container (kettle)).
10:29 p.m.
On Tuesday, February 24, 2015 18:40:41 Peter Palaga wrote:
Hi *, inline...
On 02/24/2015 05:41 PM, John Mazzitelli wrote:
> Right now I've seen version strings as 1.0-SNAPSHOT, 1.0.0-SNAPSHOT
> and 1.0.0.Alpha1-SNAPSHOT.
>
> We need to come to a consensus and be consistent. From what I
> understand, people prefer:
>
> 1.0.0-SNAPSHOT
>
> I would like to go through all our components and change their
> versions to be that. It would be nice to have our first distro
> release at least be consistent in naming of versions.
Some theory in favor of adding a qualifier such as Alpha[n], Beta[n],
CR[n] and Final : https://developer.jboss.org/wiki/JBossProjectVersioning
> In addition, its getting annoying with having to rely on release
> versions of parent pom. I'm again waiting on release 8 because I
> added a new maven plugin to the parent.
Please do not commit your own changes to the parent.
https://github.com/hawkular/hawkular-parent-pom#how-to-contribute
> We should move every pom over
> to use 8-SNAPSHOT so we can keep picking up changes. We are moving
> fast, and its slowing us down (well, me down for one) because we now
> have poms that need parent pom v6 and v7 and my stuff is waiting on
> 8. We can release when we get some kind of product out.
Do not do that. Introducing SNAPSHOT dependencies makes builds
irreproducible and unreliable. You never know which revision you get
from the SNAPSHOTs repo. Looking at today's #hawkular logs, at least
mazz, mtho11 and stefan_n know what I am speaking about.
Personally, I don't care. This early in development we don't need
reproducibility - we just need a good build with anyone's changes as quickly
as possible.
I am all for introducing all you propose once we stabilize just a little bit.
I fully understand that I am trading correctness for my own laziness (i.e. I
DO NOT want to locally rebuild all of our projects N-times a day just to be
able to use stuff people committed recently) but personally I think staying
correctly versioned at all times at this point in time is just not worth the
effort.
> There is also discussion that lucas k brought up - why not have
> version string for parent pom follow the same convention as
> everything else (that is, why not make 8-SNAPSHOT to be
> 1.0.0-SNAPSHOT instead?)
It would be quite hard to find the criteria for deciding when to
increase major, minor or micro in parent.
As far as the parent contained just maven plugins, there was no
backwards compatibility in game. I admit it is quite different now that
we manage dependencies there. But I see no way how semantic versioning
could work with the parent either.
I understand your reasoning about only having a major version number for
parent. Makes sense. But if we stuck with your strict versioning policy, we'd
end up with parent-pom version 4739 before we reached Hawkular 1.0.0.Final.
For me, that's silly.
Yes, with your approach we keep the build reproducible and perfectly
semantically correct at all times and people would be able to reliably build
even pre-alpha versions of all of our components but frankly - who does that
and what for? Devs want the absolutely latest and greatest - not something
outdated. Users are not interested in pre-alpha partly non-functioning mess.
For community involvement, I think -SNAPSHOTs are better this early in
development, because if anyone wants to start with us, we can tell them just
to use SNAPSHOTs and with high probability, the stuff will work. It might not,
true, but it will most of the times.
It think that is better dev experience than saying: "Your deps are outdated.
In the 2 days you were working on your PR, we've moved parent from 29 to 42,
inventory from 1.0.0.TIME13 to 1.0.0.TIME56, metrics from 0.2.8.TIME156 to
0.2.8.TIME824, etc, etc. Please update your PR."
As you know, I am a bit of a versioning and compatibility freak myself but we
can do all that jazz once a first (stable) version is actually out in the
wild. Before that, we're just tying our own hands, IMHO.
-- Peter
> I'll let others decide that later. I agree
> we should at least be consistent in version format for everything.
> _______________________________________________ hawkular-dev mailing
> list hawkular-dev(a)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:53 p.m.
On Wednesday, February 25, 2015 14:29:23 Lukas Krejci wrote:
On Tuesday, February 24, 2015 18:40:41 Peter Palaga wrote:
> Hi *, inline...
>
> On 02/24/2015 05:41 PM, John Mazzitelli wrote:
> > Right now I've seen version strings as 1.0-SNAPSHOT, 1.0.0-SNAPSHOT
> > and 1.0.0.Alpha1-SNAPSHOT.
> >
> > We need to come to a consensus and be consistent. From what I
> > understand, people prefer:
> >
> > 1.0.0-SNAPSHOT
> >
> > I would like to go through all our components and change their
> > versions to be that. It would be nice to have our first distro
> > release at least be consistent in naming of versions.
>
> Some theory in favor of adding a qualifier such as Alpha[n], Beta[n],
> CR[n] and Final : https://developer.jboss.org/wiki/JBossProjectVersioning
>
> > In addition, its getting annoying with having to rely on release
> > versions of parent pom. I'm again waiting on release 8 because I
> > added a new maven plugin to the parent.
>
> Please do not commit your own changes to the parent.
> https://github.com/hawkular/hawkular-parent-pom#how-to-contribute
>
> > We should move every pom over
> > to use 8-SNAPSHOT so we can keep picking up changes. We are moving
> > fast, and its slowing us down (well, me down for one) because we now
> > have poms that need parent pom v6 and v7 and my stuff is waiting on
> > 8. We can release when we get some kind of product out.
>
> Do not do that. Introducing SNAPSHOT dependencies makes builds
> irreproducible and unreliable. You never know which revision you get
> from the SNAPSHOTs repo. Looking at today's #hawkular logs, at least
> mazz, mtho11 and stefan_n know what I am speaking about.
Personally, I don't care. This early in development we don't need
reproducibility - we just need a good build with anyone's changes as quickly
as possible.
Well, I think I finally got your point. There's a difference between making a
bugfix that others need quickly and breaking changes.
Right now, everyone is fed up with waiting on bugfixes of which there are
many.
Now if we were as frequently changing the APIs of the components, people would
be equally fed up with having to adapt their own stuff to the changes made in
other components.
-SNAPSHOTs are better for bugfixes, strict versioning for API changes.
Sooo, that's what the 0.x.y versions are for, aren't they? We can depend on
snapshots for day to day (or rather hour to hour in our case at this point
time) bugfixes, but components would also bump their versions each time they
make a breaking change. 0. versions are not required to remain API compatible
in semver so the major version doesn't have to change with a breaking change.
This would work for people "waiting for a bugfix" as well as for devs needing
to move forward with breaking changes without affecting the rest of the flock
until they're ready to move.
WDYT?
I am all for introducing all you propose once we stabilize just a
little
bit. I fully understand that I am trading correctness for my own laziness
(i.e. I DO NOT want to locally rebuild all of our projects N-times a day
just to be able to use stuff people committed recently) but personally I
think staying correctly versioned at all times at this point in time is
just not worth the effort.
> > There is also discussion that lucas k brought up - why not have
> > version string for parent pom follow the same convention as
> > everything else (that is, why not make 8-SNAPSHOT to be
> > 1.0.0-SNAPSHOT instead?)
>
> It would be quite hard to find the criteria for deciding when to
> increase major, minor or micro in parent.
> As far as the parent contained just maven plugins, there was no
> backwards compatibility in game. I admit it is quite different now that
> we manage dependencies there. But I see no way how semantic versioning
> could work with the parent either.
I understand your reasoning about only having a major version number for
parent. Makes sense. But if we stuck with your strict versioning policy,
we'd end up with parent-pom version 4739 before we reached Hawkular
1.0.0.Final. For me, that's silly.
Yes, with your approach we keep the build reproducible and perfectly
semantically correct at all times and people would be able to reliably build
even pre-alpha versions of all of our components but frankly - who does
that and what for? Devs want the absolutely latest and greatest - not
something outdated. Users are not interested in pre-alpha partly
non-functioning mess.
For community involvement, I think -SNAPSHOTs are better this early in
development, because if anyone wants to start with us, we can tell them just
to use SNAPSHOTs and with high probability, the stuff will work. It might
not, true, but it will most of the times.
It think that is better dev experience than saying: "Your deps are outdated.
In the 2 days you were working on your PR, we've moved parent from 29 to
42, inventory from 1.0.0.TIME13 to 1.0.0.TIME56, metrics from 0.2.8.TIME156
to 0.2.8.TIME824, etc, etc. Please update your PR."
As you know, I am a bit of a versioning and compatibility freak myself but
we can do all that jazz once a first (stable) version is actually out in
the wild. Before that, we're just tying our own hands, IMHO.
> -- Peter
>
> > I'll let others decide that later. I agree
> > we should at least be consistent in version format for everything.
> > _______________________________________________ hawkular-dev mailing
> > list hawkular-dev(a)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
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
11:03 p.m.
Ahoj Lukáš, first of all, thanks for your patience to explain things!
More inline...
On 02/25/2015 02:53 PM, Lukas Krejci wrote:
On Wednesday, February 25, 2015 14:29:23 Lukas Krejci wrote:
> On Tuesday, February 24, 2015 18:40:41 Peter Palaga wrote:
>> Hi *, inline...
>>
>> On 02/24/2015 05:41 PM, John Mazzitelli wrote:
>>> Right now I've seen version strings as 1.0-SNAPSHOT, 1.0.0-SNAPSHOT
>>> and 1.0.0.Alpha1-SNAPSHOT.
>>>
>>> We need to come to a consensus and be consistent. From what I
>>> understand, people prefer:
>>>
>>> 1.0.0-SNAPSHOT
>>>
>>> I would like to go through all our components and change their
>>> versions to be that. It would be nice to have our first distro
>>> release at least be consistent in naming of versions.
>>
>> Some theory in favor of adding a qualifier such as Alpha[n], Beta[n],
>> CR[n] and Final : https://developer.jboss.org/wiki/JBossProjectVersioning
>>
>>> In addition, its getting annoying with having to rely on release
>>> versions of parent pom. I'm again waiting on release 8 because I
>>> added a new maven plugin to the parent.
>>
>> Please do not commit your own changes to the parent.
>> https://github.com/hawkular/hawkular-parent-pom#how-to-contribute
>>
>>> We should move every pom over
>>> to use 8-SNAPSHOT so we can keep picking up changes. We are moving
>>> fast, and its slowing us down (well, me down for one) because we now
>>> have poms that need parent pom v6 and v7 and my stuff is waiting on
>>> 8. We can release when we get some kind of product out.
>>
>> Do not do that. Introducing SNAPSHOT dependencies makes builds
>> irreproducible and unreliable. You never know which revision you get
>> from the SNAPSHOTs repo. Looking at today's #hawkular logs, at least
>> mazz, mtho11 and stefan_n know what I am speaking about.
>
> Personally, I don't care. This early in development we don't need
> reproducibility - we just need a good build with anyone's changes as quickly
> as possible.
>
Well, I think I finally got your point. There's a difference between making a
bugfix that others need quickly and breaking changes.
Right now, everyone is fed up with waiting on bugfixes of which there are
many.
Now if we were as frequently changing the APIs of the components, people would
be equally fed up with having to adapt their own stuff to the changes made in
other components.
-SNAPSHOTs are better for bugfixes, strict versioning for API changes.
Sooo, that's what the 0.x.y versions are for, aren't they? We can depend on
snapshots for day to day (or rather hour to hour in our case at this point
time) bugfixes, but components would also bump their versions each time they
make a breaking change. 0. versions are not required to remain API compatible
in semver so the major version doesn't have to change with a breaking change.
This would work for people "waiting for a bugfix" as well as for devs needing
to move forward with breaking changes without affecting the rest of the flock
until they're ready to move.
WDYT?
> I am all for introducing all you propose once we stabilize just a little
> bit. I fully understand that I am trading correctness for my own laziness
> (i.e. I DO NOT want to locally rebuild all of our projects N-times a day
> just to be able to use stuff people committed recently) but personally I
> think staying correctly versioned at all times at this point in time is
> just not worth the effort.
>
>>> There is also discussion that lucas k brought up - why not have
>>> version string for parent pom follow the same convention as
>>> everything else (that is, why not make 8-SNAPSHOT to be
>>> 1.0.0-SNAPSHOT instead?)
>>
>> It would be quite hard to find the criteria for deciding when to
>> increase major, minor or micro in parent.
>> As far as the parent contained just maven plugins, there was no
>> backwards compatibility in game. I admit it is quite different now that
>> we manage dependencies there. But I see no way how semantic versioning
>> could work with the parent either.
>
> I understand your reasoning about only having a major version number for
> parent. Makes sense. But if we stuck with your strict versioning policy,
> we'd end up with parent-pom version 4739 before we reached Hawkular
> 1.0.0.Final. For me, that's silly.
No, it is probably not going to be more than tens of versions till then,
look at JBoss Parent. Even if it was 4739, it is still shorter than 1.0.0 :)
But regardless of the above, I am open for 1.2.3 naming schema for
parent and build tools, please just propose how we are going to decide
when to increment at which level of the version. I am in favor of just
major because I do not know how it could work with 1.2.3.
Depending on SNAPSHOTs is another topic.
> Yes, with your approach we keep the build reproducible and
perfectly
> semantically correct at all times and people would be able to reliably build
> even pre-alpha versions of all of our components but frankly - who does
> that and what for? Devs want the absolutely latest and greatest - not
> something outdated. Users are not interested in pre-alpha partly
> non-functioning mess.
>
> For community involvement, I think -SNAPSHOTs are better this early in
> development, because if anyone wants to start with us, we can tell them just
> to use SNAPSHOTs and with high probability, the stuff will work. It might
> not, true, but it will most of the times.
It is nice to see that you see the consequences (thanks again for
enumerating them). Anyway, "most of the time" holds for master branches
that are up to date. As you probably see too, going back to an older
revision in a project that has SNAPSHOT deps will be less probable to
build the further one goes back in the history.
I always thought that reliable and deterministic builds are important
also during early development. Say, that in a month from now, we'll have
to compare the performance between now and then. It will be hardly
possible to build a version from today. (Is anybody asking who the hell
would need that?)
I can clearly see the trade-off and SNAPSHOT deps are a reality now.
-- P
> It think that is better dev experience than saying: "Your
deps are outdated.
> In the 2 days you were working on your PR, we've moved parent from 29 to
> 42, inventory from 1.0.0.TIME13 to 1.0.0.TIME56, metrics from 0.2.8.TIME156
> to 0.2.8.TIME824, etc, etc. Please update your PR."
>
> As you know, I am a bit of a versioning and compatibility freak myself but
> we can do all that jazz once a first (stable) version is actually out in
> the wild. Before that, we're just tying our own hands, IMHO.
>
>> -- Peter
>>
>>> I'll let others decide that later. I agree
>>> we should at least be consistent in version format for everything.
>>> _______________________________________________ hawkular-dev mailing
>>> list hawkular-dev(a)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
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)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
3358
days inactive
3360
days old
15 comments
5 participants
participants (5)
-
Heiko W.Rupp -
John Mazzitelli -
Lukas Krejci -
Peter Palaga -
Thomas Heute