7:53 a.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