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

[Hendrik Boom]

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.

x.y.z

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 
implementation.

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

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