> Whether we use Git or Tarball is orthogonal to the question if we should > update to a newer PCL version, right?
That is exactly my point. > What's the usual process in Rock for this sort of thing? Happens so rarely that there is no "usual process". IMO, for minor revisions (1.7.1 vs 1.7.2), I would directly go for a pull request. For more major changes, ask on rock-users, if there is no opposition, do it on master and advertise the change for the next release. Sylvain On Wed, Mar 16, 2016 at 1:49 PM, Martin Günther <[email protected]> wrote: > Hi Sylvain, > > On Wed, 16 Mar 2016 12:46:49 -0300 > Sylvain Joyeux <[email protected]> wrote: > >> If we were to use the git, we probably would use the latest released >> PCL version, which would not really help with the "did not get >> updated" situation. It would indeed improve the "override-ability". >> But by having everyone "update" privately, Rock as a whole loses. > > I'm not sure whether I got your point. Whether we use Git or Tarball is > orthogonal to the question if we should update to a newer PCL version, > right? > >> Updates to external packages like this usually require someone to push >> for it, because if noone wants it, then noone will bother to check >> whether the new PCL version(s) have backward compatibility issues >> (thus breaking other people's code), and noone will bother push to get >> it updated. >> >> Completely hypothetically: reasons why there has not been such a push >> might be that 1.7.1 -> 1.7.2 does not seem as huge as you are making >> it sound (at least according to >> https://github.com/PointCloudLibrary/pcl/releases). I.e. if you had >> code working on 1.7.1, 1.7.2 is not a major improvement to you. And >> that since Ubuntu 15.04, pcl is provided by binary packaged (which are >> packaging 1.7.2). >> >> Ironically, the fact that 1.7.2 is mainly a bugfix release means that >> we could pretty easily update ... but that's up to the PCL users to >> push for that change (which you are doing right now, thanks !) > > Completely agree. There are no killer features even in current > PCL master that 1.7.1 is lacking (for my use cases); on the other hand, > there have been 1000 commits between 1.7.1 and 1.7.2, and 800 more since > then. Most of them are bugfixes, but it would be nice to use them. I > regularly run into PCL bugs that have already been fixed since 1.7.1, > so I have to work around them to make my code run with 1.7.1. > > I'm not sure how I would go about checking if a PCL update would break > *other people's* code. If everyone agrees the *next* version of Rock > should upgrade to PCL 1.7.2, we should probably announce that on > rock-users and implore everyone to test their code before that next > version is released, right? What's the usual process in Rock for this > sort of thing? > > Best wishes, > Martin > > -- > Dipl.-Inf. Martin Günther > Researcher > > DFKI GmbH > Robotics Innovation Center Bremen - Außenstelle Osnabrück > ICO InnovationsCentrum Osnabrück GmbH > Albert-Einstein-Straße 1 > 49076 Osnabrück, Germany > _______________________________________________ > Rock-dev mailing list > [email protected] > http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
