On 01/04/2019 00:31, Tom Rini wrote: > On Sun, Mar 31, 2019 at 06:28:31PM -0400, Paul Barker wrote: >> On Sun, 31 Mar 2019, at 21:56, Tom Rini wrote: >>> On Sun, Mar 31, 2019 at 10:19:51PM +0200, Alexander Kanavin wrote: >>>> On Sun, 31 Mar 2019 at 22:12, Tom Rini <tr...@konsulko.com> wrote: >>>>> Looks better, thanks. Is there a particular fix / change you're doing >>>>> this for? I ask since every commit is a version bump we might want to >>>>> set a guideline of once a month or so for bumping vim to the latest. >>>> It's a bit insane upstream is doing that. >>>> Should we set PV to something like PV = "8.1+git${SRCPV}"? That way >>>> devtool/AUH/RRS will not be reporting a new version for each commit, >>>> and will only do that when 8.2 is out. >>> No, we should follow what upstream does for version numbers, it's what >>> other distros do. And on the related topic of "is it a stable branch?", >>> it does seem like yes, it is. We should just remember to not update it >>> more often than say the first of the month, without a specific reason. >> When I've done vim updates in the past I aimed for once every 3 >> months. I also looked at Debian/Fedora/etc to find a version that >> someone else has already tested in a distribution - with vim having so >> many "releases" you have the same issue you'd get from picking a >> random commit off the master branch from another project. Matching >> against a version used somewhere else gives us something to compare to >> when we hit a bug. > That's also a good idea, yes. My only concern is finding something > moving forward otherwise quickly enough, but Fedora might do well for > that.
I think it is indeed a good idea for maintainers to look up for stable projects, e.g Debian. It would be nice to have those guidelines set and clear though. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core