[Hawkular-dev] maven stuff

[Lukas Krejci]

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 at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev