[Libre-soc-dev] power-instruction-analyzer v0.2.0

Hendrik Boom hendrik at topoi.pooq.com
Thu Oct 29 11:31:56 GMT 2020

On Thu, Oct 29, 2020 at 06:25:22AM +0000, Luke Kenneth Casson Leighton wrote:
> On 10/29/20, Jacob Lifshay <programmerjake at gmail.com> wrote:
> > On Wed, Oct 28, 2020 at 5:55 PM Luke Kenneth Casson Leighton
> > <lkcl at lkcl.net> wrote:
> >>
> >> On 10/29/20, Jacob Lifshay <programmerjake at gmail.com> wrote:
> >> > I published v0.2.0 to PyPI and crates.io and created a git tag.
> >> >
> >> > I decided to change the version number since Luke was complaining
> >> > about how not changing the version number made it annoying to update.
> >>
> >> i did? oh yes if that goes through automatically to pip3 then yes,
> >> pip3 will go "nope sorry this is the same version, ain't gonna do it"
> >> :)
> >
> > maturin automatically replaces the installed version whenever you run
> > maturin develop ...
> right. and if you recall, that fails due to i think assumptions that
> it will always categorically be run under virtualenv or something,
> meaning that pip3 has to be used, which has the rule that version
> numbers must be respected.
> pip3 respecting already-installed software packages stops cascading
> hierarchical reinstalls, where a package unnecessarily reinstalls not
> just itself but all dependencies as well.
> the version number is a declaration / contract: "this software *is*
> the exact same software to the absolute last byte" and maturin, being
> inexperienced and new, doesn't yet know about these kinds of contracts
> that took 20+ years for distro systems to establish.

Back in the 70's I was on the informal committee meeting with CDC 
Netherlands on their Algol 68 compiler.

They explained their version numbering scheme for *released* software.


z was incremented for bug fixes.
y was incremented for a significant new version -- such as new features 
provided or a possibly incompatible change.
x was incremented for a new product, such as a complete new 

But I don't know what, if anything, they did for unreleased internal 

This seemed similar to the conventions that once held for Linux library 
version numbers, so that the loader could just use a version 
with a newer z value without worries; whereas changed x or y would tell 
it not to and deliberately fail if the reight version was not available.

-- hendrik

> >> fantastic.   just to check: is that required to operate normally or is
> >> it only required when running tests?
> >
> > It's required just for human inspection, not for using
> > power-instruction-analyzer.
> ahh ok.
> > Running native instruction tests requires
> > a POWER9 processor to test against, the file is basically the test
> > results, containing the calculated results for every test case.
> which could then be compared elsewhere.
> > Otherwise, you can run tests/use it on any computer that can compile it.
> okaay interesting.
> l.
> _______________________________________________
> Libre-soc-dev mailing list
> Libre-soc-dev at lists.libre-soc.org
> http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev

More information about the Libre-soc-dev mailing list