Re: [PATCH 1/3] prueth-hsr/prp: Update hsr/prp firmwares to latest

["Denys Dmytriyenko" <denys@ti.com>]

On Sun, Aug 23, 2020 at 03:10:20PM +0530, Lokesh Vutla wrote:
> Hi Denys,
> 
> On 22/08/20 12:10 am, Denys Dmytriyenko wrote:
> > On Fri, Aug 21, 2020 at 01:02:36PM +0530, Lokesh Vutla wrote:
> >> Update the hsr/prp firmwares to latest that includes support for
> >> timestamping rx packets. Unfortunately version number is not
> >> incremented for this update.
> >>
> >> Also rename the bb file to add PV in it.
> > 
> > This is fine, but you need to choose which one provides the correct PV. 
> > Currently you have it duplicated:
> > 
> > pruhsr-fw_2.15.23.bb will set PV = "2.15.23" automatically from the filename, 
> > but you also have existing PV = "2.15.23" inside the recipe. Same for other 
> > recipe.
> > 
> > The recommendation is to set PV in the filename for released tarballs.
> > 
> > When the code is pulled directly from git, it is acceptable (and sometimes 
> > even preferred) to use _git in the filename and set PV explicitly inside the 
> > recipe. And if you expect these to be updated regularly, you can avoid churn 
> > of renaming the recipe with the new version. Also that's preferred for 
> > packages (probably not in this case) that need to be AUTOREV-ed to the latest 
> > for any nightly CI atuomation...
> 
> Thanks for the explanation. Will remove the duplicate inside the FILE. Also what
> about PE and PR?

PE - Package Epoch, default "0"
PV - Package Version, default "0.0", but normally set in filename or recipe
PR - Package Revision, default "r0"

Normally PV comes from the component version. When there are any changes to 
the recipe, but PV stays the same, you want to bump the PR, though PR server 
does that function now and in most cases there's no need to do that manually.
And when the PV version goes backwards for some reason (re-version, downgrade 
or revert), then it is necessary to bump PE.


> Thanks and regards,
> Lokesh
> 
> >